Package: libtool;
Reported by: jason.vas.dias <at> gmail.com
Date: Sun, 24 Apr 2011 17:44:02 UTC
Severity: normal
Merged with 8537
Found in version 2.4
To reply to this bug, email your comments to 8542 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8542; Package libtool.
(Sun, 24 Apr 2011 17:44:02 GMT) Full text and rfc822 format available.jason.vas.dias <at> gmail.com:bug-libtool <at> gnu.org.
(Sun, 24 Apr 2011 17:44:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Jason Vas Dias <jason.vas.dias <at> gmail.com> To: bug-libtool <at> gnu.org Cc: Gordon Matzigkeit <gord <at> gnu.ai.mit.edu> Subject: 2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment Date: Fri, 22 Apr 2011 17:36:42 +0100
Hi Gordon, bug-libtool members - this is my first post to this list, so please reply to : jason.vas.dias <at> gmail.com I believe I may have found a libtool (or possibly a libtool-triggered glibc or binutils) bug : In a "setarch i686" environment on a linux-x86_64 host, where EVERYTHING (more or less) is at the latest available stable upstream version - especially : $ setarch i686 $ echo eval $(echo "307 export CC=/usr/bin/gcc' -m32' 308 export GCC=/usr/bin/gcc' -m32' 309 export CXX=/usr/bin/g++' -m32' 310 export LD=/usr/bin/ld' -melf_i386' 311 export AS=/usr/bin/as' -32' 313 export CFLAGS='-march=i686 -mtune=generic -g -O2 -fPIC -DPIC -Wa,--compress-debug-sections' 314 export LDFLAGS='-Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32,-L/usr/lib32,-L/lib32,-R/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/lib32:/usr/lib32:/lib32,--dynamic-linker,/lib32/ld-linux.so.2' " | sed 's/^[\ \ ]*[0-9]*[\ \ ]*//'); export PKG_CONFIG_PATH=/usr/lib32/pkgconfig/; export PATH=/bin/32:/usr/bin/32:/bin:/usr/bin:/sbin/32:/usr/sbin/32 eval export CC=/usr/bin/gcc' -m32' export GCC=/usr/bin/gcc' -m32' export CXX=/usr/bin/g++' -m32' export LD=/usr/bin/ld' -melf_i386' export AS=/usr/bin/as' -32' export CFLAGS='-march=i686 -mtune=generic -g -O2 -fPIC -DPIC -Wa,--compress-debug-sections' export LDFLAGS='-Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32,-L/usr/lib32,-L/lib32,-R/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/lib32:/usr/lib32:/lib32,--dynamic-linker,/lib32/ld-linux.so.2' $ ( $CC --version; $LD --version; $AS --version; ldconfig --version; libtool --version; autoconf --version; automake --version ) | egrep '[(]G' gcc (GCC) 4.6.0 GNU ld (GNU Binutils) 2.21.51.20110407 GNU assembler (GNU Binutils) 2.21.51.20110407 ldconfig (GNU libc) 2.13 libtool (GNU libtool) 2.4 autoconf (GNU Autoconf) 2.68 automake (GNU automake) 1.10.3 $ $(CC) --print-multi-os-directory ../lib32 I do for instance : $ /usr/src/poppler/configure --prefix=/usr --libdir=/usr/lib32 .... but make fails : $ make CXXLD libgoo.la Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed! make: *** [libgoo.la] Error 127 but I can do: $ cd goo/.libs $ /usr/bin/g++ -m32 -shared -Wall -Wno-write-strings -Woverloaded-virtual -Wnon-virtual-dtor -Wcast-align -fno-exceptions -fno-check-new -fno-common -g -O2 -ansi -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32,-L/usr/lib32,-L/lib32,-R/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/lib32:/usr/lib32:/lib32,--dynamic-linker,/lib32/ld-linux.so.2 -o libgoo.so $(echo gfile.lo gmempp.lo GooHash.lo GooList.lo GooTimer.lo GooString.lo gmem.lo FixedPoint.lo PNGWriter.lo JpegWriter.lo TiffWriter.lo ImgWriter.lo gstrtod.lo | sed 's/\.l/./g') -ltiff -ljpeg -lpng $ ls -l libgoo.so ; file libgoo.so -rwxr-xr-x 1 root root 151006 Apr 22 17:23 libgoo.so libgoo.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped So what is libtool trying to do here that my command isn't ? Whatever it is, glibc-2.13 doesn't like it, or it caused binutils to produce a nasty object that glibc doesn't like. Any advice / suggestions would be much appreciated. Obviously, I'll have to 'strace -f -e trace=execve make' . If you'd be interested in the log, I'll post it. Incidentally, I had to : $ rm ./libtool after the poppler configure, else I got lots of errors : $ make -j2 make all-recursive make[1]: Entering directory `/tmp/poppler' Making all in goo make[2]: Entering directory `/tmp/poppler/goo' CXX gfile.lo CXX gmempp.lo ../libtool: line 42: -32: command not found ../libtool: line 42: -32: command not found CXX GooHash.lo ../libtool: line 42: -32: command not found CXX GooList.lo ../libtool: line 42: -32: command not found But if I remove what was generated during configure as ../libtool (from goo/) , no such messages appear.
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8542; Package libtool.
(Mon, 25 Apr 2011 05:11:02 GMT) Full text and rfc822 format available.Message #8 received at 8542 <at> debbugs.gnu.org (full text, mbox):
From: Mike Frysinger <vapier <at> gentoo.org> To: jason.vas.dias <at> gmail.com Cc: Gordon Matzigkeit <gord <at> gnu.ai.mit.edu>, 8542 <at> debbugs.gnu.org Subject: Re: bug#8542: 2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment Date: Mon, 25 Apr 2011 01:10:21 -0400
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
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8542; Package libtool.
(Mon, 25 Apr 2011 14:35:02 GMT) Full text and rfc822 format available.Message #11 received at 8542 <at> debbugs.gnu.org (full text, mbox):
From: Jason Vas Dias <jason.vas.dias <at> gmail.com> To: Mike Frysinger <vapier <at> gentoo.org> Cc: Gordon Matzigkeit <gord <at> gnu.ai.mit.edu>, 8542 <at> debbugs.gnu.org Subject: Re: 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
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
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8542; Package libtool.
(Mon, 25 Apr 2011 18:04:01 GMT) Full text and rfc822 format available.Message #14 received at 8542 <at> debbugs.gnu.org (full text, mbox):
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: Re: 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
Glenn Morris <rgm <at> gnu.org>
to control <at> debbugs.gnu.org.
(Sat, 27 Aug 2011 01:29:02 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.