GNU bug report logs - #8542
2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment

Previous Next

Full log

View this message in rfc822 format

From: Todd Gamblin <tgamblin <at> llnl.gov>
To: "jason.vas.dias <at> gmail.com" <jason.vas.dias <at> gmail.com>
Cc: Gordon Matzigkeit <gord <at> gnu.ai.mit.edu>, Mike Frysinger <vapier <at> gentoo.org>, "8542 <at> debbugs.gnu.org" <8542 <at> debbugs.gnu.org>
Subject: bug#8542: 2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment
Date: Mon, 25 Apr 2011 10:46:22 -0700

Hey guys,

I'm not sure why I'm on this bug list, but in any case, could you take me off?  I don't think I have anything to do with this.

Thanks!
-Todd



On Apr 25, 2011, at 7:34 AM, Jason Vas Dias wrote:

> 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
> 
> 
> 
> _______________________________________________
> Bug-libtool mailing list
> Bug-libtool <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-libtool

________________________________________________________________________
Todd Gamblin, tgamblin <at> llnl.gov, http://people.llnl.gov/gamblin2
CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.