Error building on HP-UX

p5pRT commented 23 years ago

Migrated from rt.perl.org#4949 (status was 'resolved')

Searchable as RT4949$

p5pRT commented 23 years ago

From pnewton@gmx.de

I'm having trouble building Perl (8148) on HP-UX 10.20. It has worked previously :-).

There were also a couple of curiosities.

- at the end of configure\, it says:

Creating config.sh... Hmm...You had some extra variables I don't know about...I'll try to keep 'em... Propagating recommended variable $toke_cflags...

- then\, during make depend\, I see:

[snip] Finding dependencies for pp_ctl.o. Finding dependencies for pp_sys.o. cpp: "values.h"\, Zeile 27: Warnung 2001: Neudefinition des Makros MAXINT. Finding dependencies for regcomp.o. Finding dependencies for regexec.o. Finding dependencies for utf8.o. [snip]

(Translation: line 27: warning 2001: redefinition of macro MAXINT)

Then\, during make\, cc dies while compiling regcomp.c (warning: mucho wrapping):

Info@bx@pne /tk/users/pne/tmp/install/perl > make perl embed.pl perl warnings.pl `sh cflags libperl.a miniperlmain.o`
miniperlmain.c CCCMD = cc -DPERL_CORE -c -D_HPUX_SOURCE - DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g `sh cflags libperl.a perl.o` perl.c CCCMD = cc -DPERL_CORE -c -D_HPUX_SOURCE - DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g `sh cflags libperl.a malloc.o` malloc.c CCCMD = cc -DPERL_CORE -c -D_HPUX_SOURCE - DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g `sh cflags libperl.a gv.o` gv.c CCCMD = cc -DPERL_CORE -c -D_HPUX_SOURCE - DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g perl keywords.pl `sh cflags libperl.a toke.o` toke.c CCCMD = cc -DPERL_CORE -c -D_HPUX_SOURCE - DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -DARG_ZERO_IS_SCRIPT -g `sh cflags libperl.a perly.o` perly.c CCCMD = cc -DPERL_CORE -c -D_HPUX_SOURCE - DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g `sh cflags libperl.a op.o` op.c CCCMD = cc -DPERL_CORE -c -D_HPUX_SOURCE - DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g `sh cflags libperl.a regcomp.o` regcomp.c CCCMD = cc -DPERL_CORE -c -D_HPUX_SOURCE - DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g cc: "regcomp.c"\, line 3338: error 1654: Expression type is too large for switch expression. *** Error exit code 1

Stop.

And that's as far as it gets. Not even a miniperl.

This is with 64bitall and largefiles\, if it matters.

I can send you config.sh from the failed build or a `perl -V` output from a working Perl\, if either will help

Cheers\, Philip

p5pRT commented 23 years ago

From @jhi

    \`sh  cflags libperl\.a regcomp\.o\`  regcomp\.c
      CCCMD =  cc \-DPERL\_CORE \-c  \-D\_HPUX\_SOURCE \-
DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g cc: "regcomp.c"\, line 3338: error 1654: Expression type is too large for switch expression.

Harumph. Such weakling compilers that can't switch on a 64-bit integer :-)

*** Error exit code 1

Stop.

And that's as far as it gets. Not even a miniperl.

This is with 64bitall and largefiles\, if it matters.

Try changing this:

switch (namedclass) {

into this:

switch ((I32)namedclass) {

I can send you config.sh from the failed build or a `perl -V` output from a working Perl\, if either will help

Cheers\, Philip

p5pRT commented 23 years ago

From @tux

On Mon\, 18 Dec 2000 10:49:02 -0600\, Jarkko Hietaniemi \jhi@iki\.fi wrote:

    \`sh  cflags libperl\.a regcomp\.o\`  regcomp\.c
      CCCMD =  cc \-DPERL\_CORE \-c  \-D\_HPUX\_SOURCE \-
DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g cc: "regcomp.c"\, line 3338: error 1654: Expression type is too large for switch expression.

`sh cflags libperl.a regcomp.o` regcomp.c CCCMD = cc -DPERL_CORE -c -DDEBUGGING -Ae +DAportable -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit

Only two changes: '-g' vs. '+O2 +Onolimit' and '+DAportable'

Can you try with my flags for this one file only? Can you check cc's version in myconfig? I have "ccversion='A.10.32.30'"

Harumph. Such weakling compilers that can't switch on a 64-bit integer :-)

Well\, I just proved it does ...

*** Error exit code 1

Stop.

And that's as far as it gets. Not even a miniperl.

This is with 64bitall and largefiles\, if it matters.

Try changing this:
            switch $namedclass$ \{
into this:
            switch $\(I32$namedclass\) \{
I can send you config.sh from the failed build or a `perl -V` output from a working Perl\, if either will help

Only some cosmetic bugs here: : Finding dependencies for pp_ctl.o. Finding dependencies for pp_sys.o. cpp: "values.h"\, line 27: warning 2001: Redefinition of macro MAXINT. Finding dependencies for regcomp.o. :

All tests successful. u=1.47 s=0.63 cu=117.37 cs=18.72 scripts=248 tests=12834

And something else: I got a clean perl-5.6.0 from the tarball\, applied Sarathy's patches and got complaints from embed.pl and some others not able to write embed.h and some others. Checking the time stamps after building\, next to config.h (obviously)\, proto.h\, embed.h\, embedvar.h\, objXSUB.h and perlapi.h are touched/changed. They should therefor be writable. Also at least pod/perlapi.pod was changed during the build process. It should be writable too (unless make does not complain if it cannot update).

So yes\, I'd like to see your config.sh ...

p5pRT commented 23 years ago

From @jhi

On Mon\, Dec 18\, 2000 at 07:08:55PM +0100\, H.Merijn Brand wrote:

On Mon\, 18 Dec 2000 10:49:02 -0600\, Jarkko Hietaniemi \jhi@iki\.fi wrote:
    \`sh  cflags libperl\.a regcomp\.o\`  regcomp\.c
      CCCMD =  cc \-DPERL\_CORE \-c  \-D\_HPUX\_SOURCE \-
DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g cc: "regcomp.c"\, line 3338: error 1654: Expression type is too large for switch expression.
`sh cflags libperl.a regcomp.o` regcomp.c CCCMD = cc -DPERL_CORE -c -DDEBUGGING -Ae +DAportable -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit

Only two changes: '-g' vs. '+O2 +Onolimit' and '+DAportable'

Can you try with my flags for this one file only? Can you check cc's version in myconfig? I have "ccversion='A.10.32.30'"

Harumph. Such weakling compilers that can't switch on a 64-bit integer :-)

Well\, I just proved it does ...

If the above flags help\, good\, but I already added the (I32) cast because the same problem might crop up somewhere else. In fact\, IIRC\, it was IRIX that made me add the similar (I32) cast a little bit earlier in the code.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On 18 Dec 2000\, at 19:08\, H.Merijn Brand wrote:

[Philip Newton wrote:]

    \`sh  cflags libperl\.a regcomp\.o\`  regcomp\.c
      CCCMD =  cc \-DPERL\_CORE \-c  \-D\_HPUX\_SOURCE \-
DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -Ae -g cc: "regcomp.c"\, line 3338: error 1654: Expression type is too large for switch expression.
`sh cflags libperl.a regcomp.o` regcomp.c CCCMD = cc -DPERL_CORE -c -DDEBUGGING -Ae +DAportable -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit

Only two changes: '-g' vs. '+O2 +Onolimit' and '+DAportable'

Can you try with my flags for this one file only?

OK\, I did\, as follows:

cc -DPERL_CORE -c -DDEBUGGING -Ae +DAportable - D_HPUX_SOURCE -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit regcomp.orig.c

(I had saved the original regcomp.c as regcomp.c.orig. Since cc didn't like that ending\, I linked it to regcomp.orig.c and compiled that.)

Output:

cc: "regcomp.orig.c"\, line 3338: error 1654: Expression type is too large for switch expression.

So\, no dice :-)

Can you check cc's version in myconfig? I have "ccversion='A.10.32.30'"

ccversion='A.10.32.03'

(in myconfig)

Harumph. Such weakling compilers that can't switch on a 64-bit integer :-)

Well\, I just proved it does ...

Not my cc...

Only some cosmetic bugs here: : Finding dependencies for pp_ctl.o. Finding dependencies for pp_sys.o. cpp: "values.h"\, line 27: warning 2001: Redefinition of macro MAXINT. Finding dependencies for regcomp.o. :

Yep\, I had that\, too.

All tests successful.

...but not that (three core dumps from SIGFPE; see bugid 20001218.018).

So yes\, I'd like to see your config.sh ...

Mine? OK\, I'll attach it.

Cheers\, Philip -- Philip Newton \pnewton@gmx\.de I appreciate copies of replies to my messages to Perl5 lists.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail\, or any another MIME-compliant system\, you should be able to save it or view it from within your mailer. If you cannot\, please ask your system administrator for assistance.

---- File information ----------- File: config.sh Date: 18 Dec 2000\, 17:02 Size: 18252 bytes. Type: Text

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

config.sh

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On 18 Dec 2000\, at 12:11\, Jarkko Hietaniemi wrote:

If the above flags help\, good

They don't appear to help with the compiler I have here.

Cheers\, Philip

p5pRT commented 23 years ago

From @tux

On Tue\, 19 Dec 2000 12:09:11 +0100\, "Philip Newton" \pnewton@gmx\.de wrote:

Can you check cc's version in myconfig? I have "ccversion='A.10.32.30'"

ccversion='A.10.32.03'

(in myconfig)

Can you upgrade? (I know it doesn't solve the problem for people that are not able to upgrade\, but\, since I know they've changed *a lot*\, I'm very curious)

p5pRT commented 23 years ago

From @tux

On Tue\, 19 Dec 2000 12:09:11 +0100\, "Philip Newton" \pnewton@gmx\.de wrote:

On 18 Dec 2000\, at 19:08\, H.Merijn Brand wrote:

All tests successful.

Amazing. The test suite is obviously not complete.

...but not that (three core dumps from SIGFPE; see bugid 20001218.018).

So yes\, I'd like to see your config.sh ...

Mine? OK\, I'll attach it.

OK\, I see a lot of trouble there.

archlib='/opt/perl5/lib/5.7.0/PA-RISC2.0-64all' archlibexp='/opt/perl5/lib/5.7.0/PA-RISC2.0-64all' archname64='64all' archname='PA-RISC2.0-64all' ccflags=' -D_HPUX_SOURCE -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae' ccflags_uselargefiles='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccsymbols='_PA_RISC1_1=1 __CLASSIC_C__=1' cppccsymbols='__hp9000s800=1 __hppa=1 __hpux=1 __unix=1' cppsymbols='_FILE_OFFSET_BITS=64 _HPUX_SOURCE=1 _LARGEFILE_SOURCE=1 _LFS64_LARGEFILE=1 _LFS_LARGEFILE=1 _PA_RISC1_1=1 _PROTOTYPES=1 __STDC__=1 __STDC_EXT__=1 _XPG4=1 _XPG4_EXTENDED=1' ivdformat='"lld"' ivsize='8' ivtype='long long' myarchname='9000/861-hpux' mydomain='.datenrevision.de' myhostname='botanix' myuname='hp-ux botanix b.10.20 e 9000861 2009208003 8-user license '

a HP 9000/861 is either a G30 or a D370\, having a PA7xxx series processor\, *not* able of dealing with 64 bit arithmatic. This also shows in your ccsymbols: _PA_RISC1_1=1

I'd strongly advise *NOT* to use/test 64 bit configurations on this platform. Even with newer C-compilers some 'long long' stuff is very unpredictable. If you also have a real hppa-2.0 environment\, you can test this with +DAportable.

Did the system had an upgrade to a hppa-2.0 processor?

p5pRT commented 23 years ago

From @tux

On Wed\, 20 Dec 2000 20:03:15 +0100\, H.Merijn Brand \h\.m\.brand@hccnet\.nl wrote:

a HP 9000/861 is either a G30 or a D370\, having a PA7xxx series processor\, *not* able of dealing with 64 bit arithmatic. This also shows in your ccsymbols: _PA_RISC1_1=1

Browsing through old specifications\, I noticed they've upgraded the D370 to a PA8000 about in juli 2000. So my info was not completely true.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

archlib='/opt/perl5/lib/5\.7\.0/PA\-RISC2\.0\-64all'
archlibexp='/opt/perl5/lib/5\.7\.0/PA\-RISC2\.0\-64all'
archname64='64all'
archname='PA\-RISC2\.0\-64all'
ccflags=' \-D\_HPUX\_SOURCE \-DDEBUGGING \-I/usr/local/include \-D\_LARGEFILE\_SOURCE \-D\_FILE\_OFFSET\_BITS=64  \-Ae'
ccflags\_uselargefiles='\-D\_LARGEFILE\_SOURCE \-D\_FILE\_OFFSET\_BITS=64'
ccsymbols='\_PA\_RISC1\_1=1 \_\_CLASSIC\_C\_\_=1'
cppccsymbols='\_\_hp9000s800=1 \_\_hppa=1 \_\_hpux=1 \_\_unix=1'
cppsymbols='\_FILE\_OFFSET\_BITS=64 \_HPUX\_SOURCE=1 \_LARGEFILE\_SOURCE=1 \_LFS64\_LARGEFILE=1 \_LFS\_LARGEFILE=1 \_PA\_RISC1\_1=1 \_PROTOTYPES=1 \_\_STDC\_\_=1 \_\_STDC\_EXT\_\_=1 \_XPG4=1 \_XPG4\_EXTENDED=1'
ivdformat='"lld"'
ivsize='8'
ivtype='long long'
myarchname='9000/861\-hpux'
mydomain='\.datenrevision\.de'
myhostname='botanix'
myuname='hp\-ux botanix b\.10\.20 e 9000861 2009208003 8\-user license '

a HP 9000/861 is either a G30 or a D370\, having a PA7xxx series processor\, *not* able of dealing with 64 bit arithmatic. This also shows in your ccsymbols: _PA_RISC1_1=1

I asked at work\, and if I remember correctly our botanix is a D270\, with a 32-bit PA-RISC 2.0 processor. So no native 64 bits. (I was also told that in order to use 64-bit processors' 64 bits\, one needs at least HP-UX 11.)

I'd strongly advise *NOT* to use/test 64 bit configurations on this platform.

:-) Good advice\, I suppose\, given the SIGFPE coredumps.

Even with newer C-compilers some 'long long' stuff is very unpredictable. If you also have a real hppa-2.0 environment\, you can test this with +DAportable.

Did the system had an upgrade to a hppa-2.0 processor?

I don't know its history. But I'm told it has a 2.0 processor now.

(We also have an older machine\, node926\, which I believe is a 9000/7xx - - I think it still runs HP-UX 9. Would tests on that be helpful\, in any configuration? I could also try to get more details on its processor if you want.)

Cheers\, Philip

p5pRT commented 23 years ago

From @tux

On Thu\, 21 Dec 2000 16:02:25 +0100\, "Philip Newton" \Philip\.Newton@gmx\.net wrote:

(We also have an older machine\, node926\, which I believe is a 9000/7xx - - I think it still runs HP-UX 9. Would tests on that be helpful\, in any configuration? I could also try to get more details on its processor if you want.)

Since HP has ceased support for HP-UX 9\, I don't think it'll be usefull for the development track. P5P agrees?

p5pRT commented 23 years ago

From @doughera88

On Thu\, 21 Dec 2000\, H.Merijn Brand wrote:

On Thu\, 21 Dec 2000 16:02:25 +0100\, "Philip Newton" \Philip\.Newton@gmx\.net wrote:

(We also have an older machine\, node926\, which I believe is a 9000/7xx - - I think it still runs HP-UX 9. Would tests on that be helpful\, in any configuration? I could also try to get more details on its processor if you want.)

Since HP has ceased support for HP-UX 9\, I don't think it'll be usefull for the development track. P5P agrees?

No. Just because HP ceased support for it doesn't mean end-users aren't still using it and aren't going to be trying to build 5.8.0 there. Just look at SunOS 4.1.3 for an example of a widely-deployed system that was actively used for a long long long time after Sun had moved on to Solaris.

However\, it may be that dealing with 64-bit issues might not be a good use of our time and we might want to (by default) not even try any 64-bit stuff for HP-UX 9.

p5pRT commented 23 years ago

From @jhi

On Thu\, Dec 21\, 2000 at 02:46:39PM -0500\, Andy Dougherty wrote:

On Thu\, 21 Dec 2000\, H.Merijn Brand wrote:

On Thu\, 21 Dec 2000 16:02:25 +0100\, "Philip Newton" \Philip\.Newton@gmx\.net wrote:

(We also have an older machine\, node926\, which I believe is a 9000/7xx - - I think it still runs HP-UX 9. Would tests on that be helpful\, in any configuration? I could also try to get more details on its processor if you want.)

Since HP has ceased support for HP-UX 9\, I don't think it'll be usefull for the development track. P5P agrees?

No. Just because HP ceased support for it doesn't mean end-users aren't still using it and aren't going to be trying to build 5.8.0 there. Just look at SunOS 4.1.3 for an example of a widely-deployed system that was actively used for a long long long time after Sun had moved on to Solaris.

Exactly. A vendor abandoning a platform does not mean we have to follow the suit (if anything\, we might continue the support just out of spite...)

However\, it may be that dealing with 64-bit issues might not be a good use of our time and we might want to (by default) not even try any 64-bit stuff for HP-UX 9.

p5pRT commented 23 years ago

From @tux

On Thu\, 21 Dec 2000 13:51:12 -0600\, Jarkko Hietaniemi \jhi@iki\.fi wrote:

On Thu\, Dec 21\, 2000 at 02:46:39PM -0500\, Andy Dougherty wrote:

On Thu\, 21 Dec 2000\, H.Merijn Brand wrote:

On Thu\, 21 Dec 2000 16:02:25 +0100\, "Philip Newton" \Philip\.Newton@gmx\.net wrote:

(We also have an older machine\, node926\, which I believe is a 9000/7xx - - I think it still runs HP-UX 9. Would tests on that be helpful\, in any configuration? I could also try to get more details on its processor if you want.)

Since HP has ceased support for HP-UX 9\, I don't think it'll be usefull for the development track. P5P agrees?

No. Just because HP ceased support for it doesn't mean end-users aren't still using it and aren't going to be trying to build 5.8.0 there. Just look at SunOS 4.1.3 for an example of a widely-deployed system that was actively used for a long long long time after Sun had moved on to Solaris.

\ How likely is it that people on an old OS are upgrading to a new perl? One reason to ask is: newer perls *do* require ANSI C-compilers and with gcc having trouble with hp-ux all along the way\, and HP not changing anything\, including the C-compiler\, for HP-UX 9\, how likely is it that we have to jump through hoops to get it working on a system that probably no p5p'er is able to test it on? WIth the current feature changes leaning on newer libraries\, how feasable is it to port utf8\, perlio et all to HP-UX 9\, SunOS 4.1.3 and such? \</not disagreeing>

Exactly. A vendor abandoning a platform does not mean we have to follow the suit (if anything\, we might continue the support just out of spite...)

What do you mean with 'out of spite'? I don't know that expression\, nor does my dictionary.

However\, it may be that dealing with 64-bit issues might not be a good use of our time and we might want to (by default) not even try any 64-bit stuff for HP-UX 9.

Hmm\, I was too harsh indeed. Change hpux.sh to inhibit 64-bit anything on HP-UX less than 11.00?

Perl / perl5