Front page | perl.perl5.porters |
Postings from May 2003
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