develooper Front page | perl.perl5.porters | Postings from May 2003

Re: PATCH: hints/solaris_2.sh needs surgery

Thread Next
From:
Alan Burlison
Date:
May 15, 2003 06:26
Subject:
Re: PATCH: hints/solaris_2.sh needs surgery
Message ID:
3EC39541.8050802@sun.com
Jarkko Hietaniemi wrote:

> 	http://www.iki.fi/jhi/perl@19525.tbz

bldlog.04:XXX Build with -Duselongdouble failed
bldlog.05:XXX Build with -Dusemorebits failed
bldlog.09:XXX Build with -Duselongdouble -Duseithreads failed
bldlog.10:XXX Build with -Dusemorebits -Duseithreads failed
bldlog.14:XXX Build with -Duselongdouble -Uuseperlio failed
bldlog.15:XXX Build with -Dusemorebits -Uuseperlio failed

All caused by:

cc -L/usr/lib -L/usr/ccs/lib -L/home2/on/tools/sparc/SOS8/prod/lib 
-L/usr/local/lib -o miniperl \
miniperlmain.o opmini.o libperl.so -lsocket -lnsl -ldl -lm -lc -lrt -lposix4 
-lsunmath
Undefined                       first referenced
  symbol                             in file
frexpl                              libperl.so

which is odd, because:

Checking to see if you have fpos64_t...
frexpl() found.
<sys/param.h> found.

To cut to the chase, this is not due to any changes in perl, it is because 
I've just updated to the latest build of Solaris 10, which adds the 
following to libm:

0000088928 T  __frexpl
0000088928 t  frexpl
0000000000 f  frexpl.c

and tracing Configure shows that it does this to the output of nm:

+ /usr/bin/sed -n -e s/__IO// -e s/^.* [ADTSIW]  *_[_.]*//p \
    -e s/^.* [ADTSIW]  *//p

so it strips off any '_' characters from the front of any symbols, and 
therefore (mis)assumes that because __frexpl exists and is global, so is frexpl.

This assumption is wrong on Solaris - whilst it is *mostly* true that if 
there is an '_' symbol there will be a corresponding non-'_' symbol, it 
certainly isn't universal, and as for '__' symbols, these are commonly 
global-but-implementation-private symbols and there is absolutely *no* 
guarantee that the corresponding unadorned symbol will exist.

It seems to me that this entire approach is flawed, because it will always 
be wrong in the face of macros.  At best checking for a symbol via nm can 
only prove the presence of a particular symbol, not it's absence.  I would 
suggest that the removal of '_' from symbol names by Configure should not be 
done, and $csym should be modified to first look in the nm output 
(UU/libc.list), and if it doesn't find the symbol there it should fall 
through to using a test compile, as in the $runnm=false case.  This will be 
as fast as the existing mechanism for symbols that do exist, and slower only 
for those that don't.  However unlike the current situation, it should 
always be correct.

Thoughts?

-- 
Alan Burlison
--


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About