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

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

-- 
<URL: mailto:lvirden@cas.org> <URL: http://www.usenix.org/events/tcl2k/>
<*> O- <URL: http://www.purl.org/NET/lvirden/>  Tcl2K - Austin, Texas, US
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
-><-

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

From [Unknown Contact. See original ticket]

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.

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​: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.
-><-

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

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.

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

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

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

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

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