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

Previous Next

To reply to this bug, email your comments to 8537 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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, 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:42:32 +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.

Thank you for the otherwise great libtool and in advance for any replies !
All the best,
Jason

Message #8 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: RE: 2.4 : triggers libc "nlist > 1" assertion failure from --link in
Date: Fri, 22 Apr 2011 19:35:39 +0100

Oops, NOTABUG - this bug should be changed to be an "Enhancement Request" :

If any libtool generated shell command or pipeline fails, it should
print details of at
least the file and line number but preferably the whole command that
failed, to stderr .

What had happened was, usually I have ONLY 32-bit programs such as
/sbin/32/ldconfig
(which configures /etc/32/ld.so.cache using /etc/32/ld.so.conf ),
which absolutely must
be 32-bit, are installed on my system; but a an old non multilib
version of a 32-bit binutils got restored
(for another test) under /usr/bin/32 which I had forgotten about,  and
I had not set
$AR or $RANLIB to /usr/bin/{ar,ranlib}  . Sorry !

But I would never have raised this bug had libtool printed out something like :
  /usr/bin/32/ar failed : ...

libtool was creating an intermediary ar archive here - why ? I had not
requested --enable-static .
And what was that about the poppler generated libtool printing out
"-32 : command not found" ??

Message #11 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: RE: oops, NOTABUG - sorry, oops, STILLABUG
Date: Fri, 22 Apr 2011 19:49:33 +0100

OK, so now we get to the final link - I've totally removed the old
/usr/bin/32/ binutils stuff, and no */32 is in $PATH, but still
libtool fails:

libtool: link: g++  -fPIC -DPIC -shared -nostdlib
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/crtbeginS.o
.libs/SplashOutputDev.o .libs/DCTStream.o .libs/JPXStream.o
.libs/Annot.o .libs/Array.o .libs/BuiltinFont.o
.libs/BuiltinFontTables.o .libs/CachedFile.o .libs/Catalog.o
.libs/CharCodeToUnicode.o .libs/CMap.o .libs/DateInfo.o
.libs/Decrypt.o .libs/Dict.o .libs/Error.o .libs/FileSpec.o
.libs/FontEncodingTables.o .libs/Form.o .libs/FontInfo.o
.libs/Function.o .libs/Gfx.o .libs/GfxFont.o .libs/GfxState.o
.libs/GlobalParams.o .libs/Hints.o .libs/JArithmeticDecoder.o
.libs/JBIG2Stream.o .libs/Lexer.o .libs/Linearization.o .libs/Link.o
.libs/LocalPDFDocBuilder.o .libs/Movie.o .libs/NameToCharCode.o
.libs/Object.o .libs/OptionalContent.o .libs/Outline.o
.libs/OutputDev.o .libs/Page.o .libs/PageTransition.o .libs/Parser.o
.libs/PDFDoc.o .libs/PDFDocEncoding.o .libs/PDFDocFactory.o
.libs/PopplerCache.o .libs/ProfileData.o .libs/PreScanOutputDev.o
.libs/PSTokenizer.o .libs/Rendition.o .libs/StdinCachedFile.o
.libs/StdinPDFDocBuilder.o .libs/Stream.o .libs/strtok_r.o
.libs/UnicodeMap.o .libs/UnicodeTypeTable.o .libs/ViewerPreferences.o
.libs/XRef.o .libs/PSOutputDev.o .libs/TextOutputDev.o
.libs/PageLabelInfo.o .libs/SecurityHandler.o .libs/Sound.o
.libs/XpdfPluginAPI.o  -Wl,--whole-archive ../goo/.libs/libgoo.a
../fofi/.libs/libfofi.a ../splash/.libs/libsplash.a
-Wl,--no-whole-archive  /usr/lib32/libtiff.so -L/usr/lib32
/usr/lib32/libjpeg.so /usr/lib32/libpng15.so /usr/lib32/libfreetype.so
-lz -lfontconfig -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../..
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so -lm -lc -lgcc_s
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/crtendS.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crtn.o
-m32 -O2 -pthread -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32
-Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32 -Wl,-L/usr/lib32
-Wl,-L/lib32 -Wl,-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
-Wl,--dynamic-linker -Wl,/lib32/ld-linux.so.2   -pthread -Wl,-soname
-Wl,libpoppler.so.14 -o .libs/libpoppler.so.14.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so: could not read
symbols: File in wrong format

Message #14 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Fri, 22 Apr 2011 19:54:32 +0100

So, WHY OH WHY is libtool inserting
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64 ?
Do I need to be running some special 32-bit /usr/bin/32/libtool for
building 32-bit packages ?

Message #17 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Fri, 22 Apr 2011 20:03:51 +0100

$ gcc -m32 -print-search-dirs | grep libraries
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/
$ gcc -m32 -print-multi-os-directory
../lib32

The $LIBDIR during the poppler  build was /usr/lib32, so this can't be
an autoconf / automake issue.

If libtool is using some variant of the above gcc command to determine
the correct -L option for the gcc libraries, WHY
isn't it using the FIRST value gcc emits ?

What  libtool  should be doing instead is using something like :

  -L$(cd ${LIBDIR:-/usr/lib}/$($CC $CFLAGS -print-multi-os-directory) ; pwd;)

Message #20 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Fri, 22 Apr 2011 20:16:56 +0100

$ ls -l /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libstdc++.so{,.6.0.15}
lrwxrwxrwx 1 root root      19 Apr  8 03:50
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libstdc++.so ->
libstdc++.so.6.0.15
-rwxr-xr-x 1 root root 4554464 Apr  8 03:45
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libstdc++.so.6.0.15
[ root <at> jvdspc:/tmp/poppler 20:12:02 591:91 ]
$ cat /etc/ld.so.conf
/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


Now, the native 64-bit ld.so.conf value should NOT override in libtool
the first directory printed by 'gcc -print-search-dirs | grep
libraries'
or that found by doing 'cd ${LIBDIR:-/usr/lib}/$(gcc $CFLAGS
-print-multi-os-directory}; pwd' - because this value is what gcc uses
internally for its libraries, NOT the ld.so.conf value .

Message #23 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Fri, 22 Apr 2011 21:26:39 +0100

Wow, I'm having some luck today:

Generating a patch for the fix to this bug exposes a diffutils bug:

$ diff -U0 /tmp/libtool /usr/bin/libtool
--- /tmp/libtool        2011-04-22 21:22:30.316689243 +0100
+++ /usr/bin/libtool    2011-04-13 15:49:58.000000000 +0100
@@ -275 +275 @@
-sys_lib_search_path_spec="$(${CC:-gcc} $CFLAGS -print-search-dirs
|sed -n '/^libraries:/{s/^libraries[:=\ \       ]*//;s/:/\ /g;p}')"
+sys_lib_search_path_spec="/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64
/usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib "
[ root <at> jvdspc:/tmp/poppler 21:23:22 598:97 ]
$ diff -u /tmp/libtool /usr/bin/libtool
--- /tmp/libtool        2011-04-22 21:22:30.316689243 +0100
+++ /usr/bin/libtool    2011-04-13 15:49:58.000000000 +0100
@@ -272,7 +272,7 @@
 hardcode_into_libs=yes

 # 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}')"
+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/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/opengl/xorg-x11/lib /usr/lib32/nspr /usr/lib32/nss
/usr/java/lib32 "

Message #26 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Fri, 22 Apr 2011 21:39:03 +0100

[Message part 1 (text/plain, inline)]

PATCH :   make libtool honor gcc -print-search-dirs and
/etc/ld.so.conf properly under a '$ setarch '{alternate
sub-architecture: eg i686 on x86_64}

[ root <at> jvdspc:/tmp/poppler 21:34:17 604:103 ]
$ diff -U0 /usr/bin/libtool /tmp/libtool
--- /usr/bin/libtool    2011-04-13 15:49:58.000000000 +0100
+++ /tmp/libtool        2011-04-22 21:33:50.551636478 +0100
@@ -275 +275 @@
-sys_lib_search_path_spec="/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64
/usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib "
+sys_lib_search_path_spec="$(${CC:-gcc} $CFLAGS -print-search-dirs
|sed -n '/^libraries:/{s/^libraries[:=\ \       ]*//;s/:/\ /g;p}')"
@@ -278 +278 @@
-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/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/opengl/xorg-x11/lib /usr/lib32/nspr /usr/lib32/nss
/usr/java/lib32 "
+sys_lib_dlsearch_path_spec="cpp /etc/ld.so.conf | egrep -v '^\#' | tr '\n' ' '"
[ root <at> jvdspc:/tmp/poppler 21:37:01 605:104 ]

[libtool-8537.patch (application/octet-stream, attachment)]

Message #29 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Fri, 22 Apr 2011 22:57:40 +0100

[Message part 1 (text/plain, inline)]

more complete patch to replace last one - this one actually builds
both poppler x86_64 and poppler i686 OK .

[libtool-8537.patch (application/octet-stream, attachment)]

Message #32 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Fri, 22 Apr 2011 23:59:46 +0100

[Message part 1 (text/plain, inline)]

should be last version - please have a look - I know I have to port
this to be against the actual libtool source rather than installed
file,
but I could do with some advice here  - thanks !

On Fri, Apr 22, 2011 at 10:57 PM, Jason Vas Dias
<jason.vas.dias <at> gmail.com> wrote:
> more complete patch to replace last one - this one actually builds
> both poppler x86_64 and poppler i686 OK .
>

[libtool-8537.patch (application/octet-stream, attachment)]

Message #35 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Sat, 23 Apr 2011 00:11:59 +0100

[Message part 1 (text/plain, inline)]

version that does NOT specifiy postdep_objects or predep_objects - WHY
second guess gcc ? this works OK too.

On Fri, Apr 22, 2011 at 11:59 PM, Jason Vas Dias
<jason.vas.dias <at> gmail.com> wrote:
> should be last version - please have a look - I know I have to port
> this to be against the actual libtool source rather than installed
> file,
> but I could do with some advice here  - thanks !
>
> On Fri, Apr 22, 2011 at 10:57 PM, Jason Vas Dias
> <jason.vas.dias <at> gmail.com> wrote:
>> more complete patch to replace last one - this one actually builds
>> both poppler x86_64 and poppler i686 OK .
>>
>

[libtool-8537.patch (application/octet-stream, attachment)]

Message #38 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: 8537 <at> debbugs.gnu.org
Subject: Re: oops, NOTABUG - sorry, oops, STILLABUG
Date: Sat, 23 Apr 2011 00:19:40 +0100

[Message part 1 (text/plain, inline)]

version that DOES set predep_objects and postdep_objects - appears to
be no difference - both work for x86_64 + i686 poppler build - so why
specify the crt* objects when gcc does this OK ?

[libtool-8537.patch (application/octet-stream, attachment)]

Message #41 received at 8537 <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: 8537 <at> debbugs.gnu.org, 8557 <at> debbugs.gnu.org
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
Date: Thu, 28 Apr 2011 00:55:33 +0100

On Wednesday 27 April 2011 04:14:21 you wrote:
> On Tue, Apr 26, 2011 at 19:48, Jason Vas Dias wrote:
> > And my major primary central questions to the whole libtool community raised in several bug reports (both inadvertently by replying to 'bug-libtool' and
> > intentionally by creating different bugs - sorry ! - there should be only two:  #8537 and #8557 ) is :
> >
> > WHY IS LIBTOOL NOT SETTING $sys_lib_search_path_spec DYNAMICALLY BASED ON $CFLAGS CONTAINING -m$ARCH FLAGS ?
> > WHY IS LIBTOOL SPECIFYING -nostdlibs  -nostdlib \$predep_objects AND SPECIFYING ALL THE "crt*.o" C-RUNTIME OBJECTS ON A GCC / Linux PLATFORM ?
> 
> drop the caps crap.
> 
> the libtool as found in $PATH targets the toolchain is was configured
> for.  this is why libtool is always packaged/generated with the build
> system in packages that use it ... when you configure/build the
> package for a specific target, the local ./libtool is compiled
> properly for that target.  attempting to use `libtool` for anything
> other than the native gcc really isnt its intended use.
> 
> perhaps in the future this might change as an enhancement, but today,
> it sounds like you're just using it wrong.
> -mike
> 
Hi Mike - thanks for responding ! Sorry, I didn't realize capitals were somehow offensive.

RE:  >  the libtool as found in $PATH targets the toolchain is was configured for

Yes,  I know this,  but perhaps I made insufficiently clear what led to me raising these
bugs was the errors / anomalies observed when just running ./libtool via
"configure" / "autogen.sh" and "make" .
Then I looked at the /usr/bin/libtool to see what it was doing that could shed light on these bugs; 
that's the only program that libtool installs from its source that one can test , and is mentioned
in the documentation - many of the documentation examples would fail if the $CFLAGS used in
them selects a different $sys_lib_search_path , because the /usr/bin/libtool program would use
the wrong $sys_lib_search_path_spec setting .

For bug 8537, this was a combination of poppler's libtool using '-nostdlibs' and triggering glibc bug #12454 ,
and for bug 8557, this was mainly because of that stdc++.la being referenced in some installed /usr/lib*/*.la file.

Perhaps a really nice new feature for libtool would be some option to make all libtool scripts not install any .la files in /{,lib,usr/lib}*/  
and to ignore any .la files found there ? Or at least, when some .la is not found, to print which .la it was sourcing that caused it to
look for the missing .la ? ( Some ".la backtrace" feature ? )

And why if the $CFLAGS makes gcc look in /usr/lib32 first , and never look in /usr/lib64, should ANY libtool script be looking for a 32-bit .la 
or anything  in /usr/lib64/ ?

I thought perhaps it was because those compiled scripts somehow inherited the sys_lib_search_path_spec setting behaviour from
the /usr/bin/libtool script . Why install /usr/bin/libtool if it is not meant to be used for anything but gcc ?

Anyway, installing libtool from the GIT head (requiring upgrade to automake-1.11a) seemed to fix the poppler build problem so I guess these
bugs can be closed if noone thinks there are any valid issues raised by them - sorry if this is the case.

I'd like to investigate further exactly why the poppler lib32 build specified -nostdlibs and triggered glibc bug 12454 with libtool-2.4.1 and automake 1.10.3 
but did not with libtool-2.4.1a and automake-1.11a  .

And I'd still like an answer to the basic question "why is libtool doing so much on Linux when gcc gets it right on its own" ?
I don't think libtool should be doing things like forcing a library search path and -nostdlibs and predep_objects and postdep_objects
on gcc when it doesn't actually need to - ie unless there are exceptional circumstances when it is actually required . But this seems to be libtool's default behavior.
I'm curious as to what the rational is in forcing -nostdlib builds that explicitly specify all the CRT objects when gcc generally does this fine,
except in very rare and exceptional circumstances.

But thanks for your help,
all the best,
Jason

Message #44 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: jason.vas.dias <at> gmail.com
Cc: 8537 <at> debbugs.gnu.org, 8557 <at> debbugs.gnu.org
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
Date: Thu, 28 Apr 2011 07:59:05 -0400

On Wed, Apr 27, 2011 at 19:55, Jason Vas Dias wrote:
> Then I looked at the /usr/bin/libtool to see what it was doing that could shed light on these bugs;
> that's the only program that libtool installs from its source that one can test , and is mentioned
> in the documentation - many of the documentation examples would fail if the $CFLAGS used in
> them selects a different $sys_lib_search_path , because the /usr/bin/libtool program would use
> the wrong $sys_lib_search_path_spec setting .

yes, and that is currently expected behavior

> Perhaps a really nice new feature for libtool would be some option to make all libtool scripts
> not install any .la files in /{,lib,usr/lib}*/ and to ignore any .la files found there ?

i dont think that'd be useful

> Or at least, when some .la is not found, to print which .la it was sourcing that caused it to
> look for the missing .la ? ( Some ".la backtrace" feature ? )

if you run with --debug, you can grep for .la files in the output

although it's usually pretty easy to just look at the output and
guess.  if libtool is invoked with -lfoo and the verbose output from
libtool says /usr/lib/libfoo.so, it most likely hit an .la file for
it.

> And why if the $CFLAGS makes gcc look in /usr/lib32 first , and never look in /usr/lib64, should ANY
> libtool script be looking for a 32-bit .la or anything  in /usr/lib64/ ?

hardcoding 64bit:/usr/lib64 and 32bit:/usr/lib32 doesnt make sense ...
these are arbitrary conventions picked by gcc specifically for
i686/x86_64 linux targets.  libtool has no concept of multilib today
which is why you have to configure libtool specifically for each
build.

> I thought perhaps it was because those compiled scripts somehow inherited the
> sys_lib_search_path_spec setting behaviour from the /usr/bin/libtool script . Why
> install /usr/bin/libtool if it is not meant to be used for anything but gcc ?

ultimately this decision is up to your distro provider, but installing
the default libtool is useful for building/linking with the
default/native target.  there are also (poorly written) packages that
invoke `libtool` from $PATH instead of bundling its own local version.

> And I'd still like an answer to the basic question "why is libtool doing so much on Linux
> when gcc gets it right on its own" ?

your view of libtool is clouded by your very narrow focus on recent
versions of gcc/Linux targets.  libtool scales to many many more
targets, and its complex system is designed to handle severly
deficient targets.  albeit at the cost of being more complex than
necessary for some modern/sane targets.
-mike

Message #47 received at 8537 <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: 8537 <at> debbugs.gnu.org, 8557 <at> debbugs.gnu.org
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
Date: Thu, 28 Apr 2011 20:04:56 +0100

On Thursday 28 April 2011 12:59:05 Mike Frysinger wrote:
> > And I'd still like an answer to the basic question "why is libtool doing so much on Linux
> > when gcc gets it right on its own" ?
> 
> your view of libtool is clouded by your very narrow focus on recent
> versions of gcc/Linux targets.  libtool scales to many many more
> targets, and its complex system is designed to handle severly
> deficient targets.  albeit at the cost of being more complex than
> necessary for some modern/sane targets.
> -mike

But I, as the end user and "distro maintainer" of my own distro, want to produce a compatible
version of libtool for linux for use on it that does not do anything too complicated unless it needs to .

I've always greatly admired autoconf, automake and libtool for their ability to build and install 
software on such a huge variety of platforms, but always hated trying to get them to build
and install software that is truly optimized for only one OS and toolchain .

With a "one size fits all" approach, it is too easy to make all software perform equally poorly on all platforms -
I'm not saying autoconf / automake / libtool does this, but it enforces alot of complicated configuration operations on platforms where
literally typing 'make c.o' where 'c.c' exists will do the job without anything else at all (no Makefile required even) .

I'm developing a 100% GNU make(1) and bash(1) and coreutils dependant replacement for the "configure" step - NO other dependancies required -
that will generate  'Makefile's and ./libtool with very simple commands if it finds itself to be running on a "quick configure platform" , it will skip configure 
and just generate simple autoconf generated files.
I have a make library that can source and execute m4 configure macros,  and could make it construct a "configure" script and "libtool" script in make 
"define ... endef"s that can be dumped to files or sourced . Personally, I prefer programming in GNU make(1) and using macro processors such
as cpp or autotext or the shell to programming in m4 , and there is no reason why this shouldn't be permitted on platforms with a fully functional
GNU development tools and utilities toolchain .

I'll post the results to libtool-devel <at> gnu.org or whatever it should be sent when this is complete and fully tested (for Linux at least).

All the best,
Jason

Message #50 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: jason.vas.dias <at> gmail.com
Cc: 8537 <at> debbugs.gnu.org, 8557 <at> debbugs.gnu.org
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
Date: Thu, 28 Apr 2011 17:58:25 -0400

On Thu, Apr 28, 2011 at 15:04, Jason Vas Dias wrote:
> I'm developing a 100% GNU make(1) and bash(1) and coreutils dependant replacement for the "configure" step - NO other dependancies required -
> that will generate  'Makefile's and ./libtool with very simple commands if it finds itself to be running on a "quick configure platform" , it will skip configure
> and just generate simple autoconf generated files.

search the mailing list.  some people have already thrown together
similar things.
-mike

Previous Next

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