Closed p5pRT closed 20 years ago
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
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
From: Dominic Dunlop \domo@​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.
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​:lvirden@​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. ->\<-
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
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.
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
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
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
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
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
Migrated from rt.perl.org#2075 (status was 'resolved')
Searchable as RT2075$