[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8542: 2.4 : triggers libc "nlist > 1" assertion failure from --link
From: |
Jason Vas Dias |
Subject: |
bug#8542: 2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment |
Date: |
Mon, 25 Apr 2011 15:34:09 +0100 |
User-agent: |
KMail/1.12.4 (Linux/2.6.38.2-jvd; KDE/4.3.4; x86_64; svn-1073138; 2010-01-11) |
On Monday 25 April 2011 06:10:21 Mike Frysinger wrote:
> On Fri, Apr 22, 2011 at 12:36 PM, Jason Vas Dias wrote:
> > $ make
> > CXXLD libgoo.la
> > Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps:
> > Assertion `nlist > 1' failed!
>
> sounds like the glibc bug:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=12454
> -mike
>
Hi Mike - thanks for responding -
but this was an inadvertent resend from my mailer of a "draft" , a copy of
which I had sent by other means, to create bug :
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8537
this turned out to be nothing to do with glibc, but with why the libtool script
says:
/usr/bin/libtool @line 274 :
# Compile-time system search path for libraries.
sys_lib_search_path_spec="/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64 /usr/lib64
/lib64 /usr/x86_64-pc-linux-gnu/lib "
# Run-time system search path for libraries.
sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/lib64 /lib64
/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0 /usr/lib64/nspr /usr/lib64/nss
/usr/qt/4.6/lib64 /usr/kde/4.3/lib64 /usr/java/lib64 /usr/lib32 /lib32
/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32 /usr/lib32/nspr /usr/lib32/nss
/usr/java/lib32 "
when I think it should be saying something like :
# Compile-time system search path for libraries.
sys_lib_search_path_spec="$(${CC:-gcc} $CFLAGS -print-search-dirs |sed -n
'/^libraries:/{s/^libraries[:=\ \ ]*//;s/:/ /g;p}')"
# Run-time system search path for libraries.
sys_lib_dlsearch_path_spec="sed 's/^include/\#include/ < /etc/ld.so.conf | cpp
- | egrep -v '^\#' | tr '\n' ' '"
ie. how can libtool hope to get the multi-lib search path correct if it is NOT
dynamic and dependant on $CFLAGS ?
ie. my gcc-4.6.0 produces radically different library search values for 32-bit
and 64-bit :
$ gcc -print-search-dirs ; echo multi-os:; gcc -print-multi-os-directory
install: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/
programs:
=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/
libraries:
=/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/
multi-os:
../lib64
$ gcc -m32 -print-search-dirs ; echo multi-os:; gcc -m32
-print-multi-os-directory
install: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/
programs:
=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/
libraries:
=/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/../lib32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/:/lib/x86_64-pc-linux-gnu/4.6.0/32/:/lib/../lib32/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib/../lib32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib/
multi-os:
../lib32
So why can't the installed libtool script invoke "$($CC $CFLAGS
-print-search-dirs)" dynamically to determine the library search path ?
If it did, it would function correctly for "naive" libtool users such as
poppler which are totally unaware of any multi-lib / multi-arch
environment, as well as for "sophisticated" libtool using libraries such as
cairo, which DO build correctly for 32-bit - both my
dynamic version and the installed hard-coded version - I can't quite understand
why yet, but I think the cairo build scripts are
just better honoring my $CFLAGS / $LDFLAGS settings, and if they were not set
libtool would still fail for 32-bit sub-arch
cairo build on x86_64 ; ie. with my "dynamic setting of
sys_lib_search_path_spec", I would not need to set $LDFLAGS to such
a complicated value and libtool would work correctly if I just set CFLAGS=-m32 .
Also, why does libtool insist on supplying explicit paths to the "c runtime
startup" (CRT) files : crti.o crtbeginS.o crtn.o crtendS.o -
when GCC supplies these automatically and 100% correctly for its "-mXX" args ?
To me, that is just another unecessary way
that libtool can fail .
I'd greatly appreciate it if you could take a look at bug #8537 - do you think
a patch along the lines detailed therein would be
considered for libtool ? (obviously the final patch would be against the script
SOURCE, not the installed script, as it is currently).
Thanks & Regards ,
Jason Vas Dias