Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.85k stars 527 forks source link

Unable to build latest perl #1117

Closed p5pRT closed 20 years ago

p5pRT commented 24 years ago

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

Searchable as RT2075$

p5pRT commented 24 years ago

From lvirden@cas.org

Created by lvirden@cas.org

This is a bug report for perl from lvirden@​cas.org\, generated with the help of perlbug 1.27 running under perl 5.00563.

----------------------------------------------------------------- Of course\, the bottom part of this isn't really relevant...

After running Configure I do a make all and see\, after a while the following. What's weird is that one would think that perl would be able to find these items... This is Solaris 2.6\, Ultra SPARC 5\, Sun's compiler.

cc -R/projects/gnu/sparc-sun-solaris2.6/lib​:/vol/lwv26ldatae/lib​:/usr/ccs/lib -L/projects/gnu/sparc-sun-solaris2.6/lib -L/vol/lwv26ldatae/lib -L/usr/ccs/lib -o miniperl \   miniperlmain.o opmini.o libperl.a -lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lsec Undefined first referenced symbol in file Perl_log libperl.a(pp.o) Perl_sin libperl.a(pp.o) Perl_cos libperl.a(pp.o) Perl_exp libperl.a(pp.o) Perl_atan2 libperl.a(pp.o) Perl_modf libperl.a(pp.o) Perl_fmod libperl.a(pp.o) Perl_sqrt libperl.a(pp.o) Perl_floor libperl.a(pp.o) ld​: fatal​: Symbol referencing errors. No output written to miniperl make​: *** [miniperl] Error 1

Perl Info ``` Site configuration information for perl 5.00563: Configured by lwv26 at Mon Dec 20 02:35:39 EST 1999. Summary of my perl5 (revision 5.0 version 5 subversion 63) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos lwv26awu 5.6 generic_105181-16 sun4u sparc sunw,ultra-5_10 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef use64bits=undef usemultiplicity=undef Compiler: cc='cc', optimize='-g', gccversion= cppflags='-DDEBUGGING' ccflags ='-DDEBUGGING -DUSE_LONG_LONG -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='cc', ldflags ='-R/projects/gnu/sparc-sun-solaris2.6/lib:/vol/lwv26ldatae/lib:/usr/ccs/lib -L/projects/gnu/sparc-sun-solaris2.6/lib -L/vol/lwv26ldatae/lib -L/usr/ccs/lib ' libpth=/projects/gnu/sparc-sun-solaris2.6/lib /vol/lwv26ldatae/lib /usr/ccs/lib /usr/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lsec libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-KPIC', lddlflags='-R/projects/gnu/sparc-sun-solaris2.6/lib:/vol/lwv26ldatae/lib:/usr/ccs/lib -G -L/projects/gnu/sparc-sun-solaris2.6/lib -L/vol/lwv26ldatae/lib -L/usr/ccs/lib' Locally applied patches: @INC for perl 5.00563: /home/lwv26/lib/perl5/ /projects/sprs_lwv/lib/perl5/ /vol/lwv26ldatae/lib/perl5/5.006/sun4-solaris /vol/lwv26ldatae/lib/perl5/5.006 /vol/lwv26ldatae/lib/site_perl/5.006/sun4-solaris /vol/lwv26ldatae/lib/site_perl . Environment for perl 5.00563: HOME=/home/lwv26 LANG=C LANGUAGE (unset) LD_LIBRARY_PATH=/lprod/cas/lib:/usr/dt/lib:/usr/openwin/lib:/usr/lib LOGDIR (unset) PATH=/opt/SUNWspro/bin:/ldatae/bin:/projects/sprs_lwv/sol26/bin:/projects/sprs_lwv/sol26/bin/mime:/projects/sprs_lwv/sol2/bin:/projects/sprs_lwv/bin:/projects/sprs_lwv/bin/mime:/home/lwv26/bin/D.news:/usr/perl5/bin:/projects/gnu/sparc-sun-solaris2.6/bin:/usr/tcl82/sun4/bin:/usr/tcl82/bin:/projects/xopsrc/sun4/bin:/projects/xopsrc/bin:/usr/atria/bin:/projects/intranet/bin:/projects/clearcase/bin:/vol/tclsrcsol/TclPro1.3/solaris-sparc/bin:/ldata2/teTeX/bin/sparc-sun-solaris2.6:/vol/adobe/Acrobat3/bin:/ldata/bin:/home/lwv26/bin/D.aws:/home/lwv26/bin/sol2:/home/lwv26/bin/D.frontend:/home/lwv26/bin/D.ksh:/cas/test/bin/sun4:/projects/sprs_lwv/bin/sol2:/usr/java1.2/bin:/home/lwv26/bin/sun4:/lprod/cas/bin:/usr/local/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/cas/bin/sun4:/cas/abin/sun4:/cas/X11/sun4/bin:/usr/ccs/bin:/uprod/bin:/usr/sbin:/cas/tools/bin/sun4:/cas/X11/sun4/tools/bin:/usr/ucb:/home/lwv26/bin:/cas/tools/pdbin/sun4:/home/lwv26/bin/D.mistypes:/home/lwv26/bin/D.toys:/home/lwv! 26/bin/D.tools:/projects/npd/npdweb/bin-sol2 PERL5LIB=/home/lwv26/lib/perl5/:/projects/sprs_lwv/lib/perl5/: PERLDOC=-t PERLLIB=/home/lwv26/lib/perl:/projects/sprs_lwv/lib/perl: PERL_BADLANG (unset) SHELL=/bin/ksh -- <*> O- Tcl2K - Austin, Texas, US Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -><- ```
p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

At 17​:08 -0500 2000-02-02\, Larry W. Virden wrote​:

miniperlmain\.o opmini\.o libperl\.a \-lsocket \-lnsl \-lgdbm \-ldb 

-ldl -lm -lc -lcrypt -lsec

Try putting -lcrypt -lsec ahead of -lm??? Just a wild guess...

-- Dominic Dunlop

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

From​: Dominic Dunlop \domo@&#8203;computer\.org

  At 17​:08 -0500 2000-02-02\, Larry W. Virden wrote​:   > miniperlmain.o opmini.o libperl.a -lsocket -lnsl -lgdbm -ldb   >-ldl -lm -lc -lcrypt -lsec  
  Try putting -lcrypt -lsec ahead of -lm??? Just a wild guess...  
 
I also moved -ldl to the end of the list. Seems like that would be most prudent...

Unfortunately\, it didn't help.

-- Larry W. Virden \<URL​: mailto​:lvirden@​cas.org> Tcl2K \<URL​: http​://www.purl.org/NET/lvirden/>\<URL​:http​://www.usenix.org/event s/tcl2k/> Unless explicitly stated to the contrary\, nothing in this posting should be construed as representing my employer's opinions.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Well\, more on this problem. I had some time to look more into this situation. Here is the problem . The configure asked me if I wanted to try Long Doubles. I indicated yes\, and the configure in fact appeared to find them. Code then encountered​:

#ifdef USE_LONG_DOUBLE # define NV_DIG LDBL_DIG # ifdef HAS_SQRTL # define Perl_modf modfl # define Perl_frexp frexpl # define Perl_cos cosl # define Perl_sin sinl # define Perl_sqrt sqrtl # define Perl_exp expl # define Perl_log logl # define Perl_atan2 atan2l # define Perl_pow powl # define Perl_floor floorl # define Perl_fmod fmodl # endif

But Solaris 2.6 doesn't HAVE a sqrtl or the other long math functions. So I end up with Perl_modf\, etc. not being defined\, and resulting in unresolved references. I will change my answer to Configure - but it sort of seems to me that once Configure sees that I don't have those functions\, it should turn off the use long double or else point to some compatibility functions... -- Larry W. Virden \mailto&#8203;:lvirden@&#8203;cas\.org\<http​://www.usenix.org/events/tcl2k/> \<URL​: http​://www.purl.org/NET/lvirden/> \<*> O- Unless explicitly stated to the contrary\, nothing in this posting should be construed as representing my employer's opinions. ->\<-

p5pRT commented 24 years ago

From @doughera88

On Wed\, 2 Feb 2000\, Larry W. Virden wrote​:

Of course\, the bottom part of this isn't really relevant...

After running Configure I do a make all and see\, after a while the following. What's weird is that one would think that perl would be able to find these items... This is Solaris 2.6\, Ultra SPARC 5\, Sun's compiler.

cc -R/projects/gnu/sparc-sun-solaris2.6/lib​:/vol/lwv26ldatae/lib​:/usr/ccs/lib -L/projects/gnu/sparc-sun-solaris2.6/lib -L/vol/lwv26ldatae/lib -L/usr/ccs/lib -o miniperl \ miniperlmain.o opmini.o libperl.a -lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lsec Undefined first referenced symbol in file Perl_log libperl.a(pp.o) Perl_sin libperl.a(pp.o)

[ etc. ]

Summary of my perl5 (revision 5.0 version 5 subversion 63) configuration​: Platform​:

ccflags ='\-DDEBUGGING \-DUSE\_LONG\_LONG \-D\_LARGEFILE\_SOURCE \-D\_FILE\_OFFSET\_BITS=64'

d\_longlong=define\, longlongsize=8\, d\_longdbl=define\, longdblsize=16

The problem here is that perl ended up trying to use long doubles (I think as part of the long_long support) but when it came to finding math functions that could handle those long doubles\, perl.h didn't know what to do.

Don't try to tackle this problem further in _63. A very quick glance at 5.5.640 shows that there are some new #ifdefs in there to try to help catch this problem. I don't know offhand whether it will work\, but it's a better place to start trying.

Also\, if you were using -DUSE_LONG_LONG to try to get stat() and friends to work correctly on large files\, 5.5.640 is supposed to contain code to try to do so without the need to make all IVs into long longs. We need folks to test this out\, of course\, so test results both with and without long long would be welcome.

  Andy Dougherty doughera@​lafayette.edu   Dept. of Physics   Lafayette College\, Easton PA 18042

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Actually\, I was using version 64\, which I think was what was causing the problem.

The problem is that with 64\, Configure tries REALLY hard to get me to use long long and long doubles. That's because the C compiler recognizes those constructs for C. Unfortunately\, Configure doesn't find any comperable math library (at least one called {function}l .

-- Larry W. Virden \<URL​: mailto​:lvirden@​cas.org> Tcl2K \<URL​: http​://www.purl.org/NET/lvirden/>\<URL​:http​://www.usenix.org/event s/tcl2k/> Unless explicitly stated to the contrary\, nothing in this posting should be construed as representing my employer's opinions.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Andy Dougherty writes​:

Don't try to tackle this problem further in _63. A very quick glance at 5.5.640 shows that there are some new #ifdefs in there to try to help catch this problem. I don't know offhand whether it will work\, but it's a better place to start trying.

I have a very minor complaint about this new stuff. The sniffing for 64-bitness is not done if it is not needed by Perl. Why? This can make writing extensions harder...

Ilya

p5pRT commented 24 years ago

From @jhi

Ilya Zakharevich writes​:

Andy Dougherty writes​:

Don't try to tackle this problem further in _63. A very quick glance at 5.5.640 shows that there are some new #ifdefs in there to try to help catch this problem. I don't know offhand whether it will work\, but it's a better place to start trying.

I have a very minor complaint about this new stuff. The sniffing for 64-bitness is not done if it is not needed by Perl. Why? This can

Please explain. I thought just the opposite is happening​: 64-bitness sniffing is done *always*\, regardless of -Duse64bits.

make writing extensions harder...

Ilya

-- $jhi++; # http​://www.iki.fi/jhi/   # There is this special biologist word we use for 'stable'.   # It is 'dead'. -- Jack Cohen

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Fri\, Feb 04\, 2000 at 08​:27​:30AM +0200\, Jarkko Hietaniemi wrote​:

Please explain. I thought just the opposite is happening​: 64-bitness sniffing is done *always*\, regardless of -Duse64bits.

H​:\get\perl\perl5.5.640>perl -Ilib -V​:.*64.* archname64='' d_PRIX64='undef' d_PRId64='undef' d_PRIi64='undef' d_PRIo64='undef' d_PRIu64='undef' d_PRIx64='undef' d_fpos64_t='undef' d_int64t='undef' d_off64_t='undef' i64size='' i64type='' sPRIX64='' sPRId64='' sPRIi64='' sPRIo64='' sPRIu64='' sPRIx64='' u64size='' u64type='' use64bits='undef'

This is gcc\, which (of course) has long long (and Configure correctly determined this).

Ilya

p5pRT commented 24 years ago

From @jhi

Ilya Zakharevich writes​:

On Fri\, Feb 04\, 2000 at 08​:27​:30AM +0200\, Jarkko Hietaniemi wrote​:

Please explain. I thought just the opposite is happening​: 64-bitness sniffing is done *always*\, regardless of -Duse64bits.

H​:\get\perl\perl5.5.640>perl -Ilib -V​:.*64.* archname64='' d_PRIX64='undef' d_PRId64='undef' d_PRIi64='undef' d_PRIo64='undef' d_PRIu64='undef' d_PRIx64='undef' d_fpos64_t='undef' d_int64t='undef' d_off64_t='undef' i64size='' i64type='' sPRIX64='' sPRId64='' sPRIi64='' sPRIo64='' sPRIu64='' sPRIx64='' u64size='' u64type='' use64bits='undef'

This is gcc\, which (of course) has long long (and Configure correctly determined this).

Hmmm. Oh\, now I think I know why this happens. Because of backward compatibility (=trying not to break things) the "long long" is *not* implicitly picked up as the 64-bit type to use\, even if it is the only 64-bit type available (one has to explicitly -Duse64bits in that case).

Yes\, we could change the current default of not using "long long" unless explicitly told so. But if we combine that with the new idea of always trying to use large files\, too\, if possible\, I think we may in some platforms cause "long long" to be used inadvertently.

Ilya

-- $jhi++; # http​://www.iki.fi/jhi/   # There is this special biologist word we use for 'stable'.   # It is 'dead'. -- Jack Cohen

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Fri\, Feb 04\, 2000 at 08​:44​:50AM +0200\, Jarkko Hietaniemi wrote​:

Hmmm. Oh\, now I think I know why this happens. Because of backward compatibility (=trying not to break things) the "long long" is *not* implicitly picked up as the 64-bit type to use\, even if it is the only 64-bit type available (one has to explicitly -Duse64bits in that case).

Yes\, we could change the current default of not using "long long" unless explicitly told so. But if we combine that with the new idea of always trying to use large files\, too\, if possible\, I think we may in some platforms cause "long long" to be used inadvertently.

Large files work now without long long\, right? (For some value of large ;-). So\, what is the problem?

Ilya