Package: libtool;
To reply to this bug, email your comments to 8557 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#8557; Package libtool.
(Tue, 26 Apr 2011 10:38:02 GMT) Full text and rfc822 format available.jason.vas.dias <at> gmail.com:bug-libtool <at> gnu.org.
(Tue, 26 Apr 2011 10:38: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 Subject: libtool run against newly built libraries fails in setarch 'i686' Date: Tue, 26 Apr 2011 11:37:11 +0100
Hi - when running in a 32-bit environment on a native x86_64 linux host,
attempting to build gtk+-2.24.4 fails because libtool incorrectly links
a newly built executable to /usr/lib32/ libgdk-x11-2.0.so.0, not to
../../gtk/.libs/libgdk-x11-2.0.so.0 :
ENVIRONMENT:
I source this file to setup an i686 build environment in a 'setarch i686' shell instance :
$ cat ~/32.bit.env
declare -x ARCH=i686
declare -x AS="/usr/bin/as -32"
declare -x ASFLAGS="-Wa,-32"
declare -x CFLAGS="-march=i686 -mtune=generic -g -O2 -fPIC -DPIC -Wa,--compress-debug-sections"
declare -x LD="/usr/bin/ld -melf_i386"
declare -x 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"
declare -x PATH="/bin:/usr/bin:."
declare -x PKG_CONFIG_PATH="/usr/lib32/pkgconfig/"
$ setarch i686
$ . ~/32.bit.env
And, trying to build gtk+2.0 (v 2.24.4 ) , it fails :
libtool: link: ( cd ".libs" && rm -f "im-viqr.la" && ln -s "../im-viqr.la" "im-viqr.la" )
libtool: link: /usr/bin/gcc -m32 -shared -fPIC -DPIC .libs/gtkimcontextxim.o .libs/imxim.o -Wl,-rpath -Wl,/tmp/gtk+/gdk/.libs -Wl,-rpath -Wl,/tmp/gtk+/gtk/.libs -L/tmp/gtk+/gdk/.libs ../../gdk/.libs/libgdk-x11-2.0.so -L/usr/lib32 ../../gtk/.libs/libgtk-x11-2.0.so /tmp/gtk+/gdk/.libs/libgdk-x11-2.0.so /usr/lib32/libXinerama.so /usr/lib32/libXrandr.so -lXext /usr/lib32/libXcursor.so /usr/lib32/libpangocairo-1.0.so /usr/lib32/libXcomposite.so /usr/lib32/libXdamage.so /usr/lib32/libXfixes.so /usr/lib32/libatk-1.0.so /usr/lib32/libcairo.so /usr/lib32/libpixman-1.so -lEGL /usr/lib32/libpng15.so /usr/lib32/libxcb-dri2.so -ludev /usr/lib32/libxcb-shm.so /usr/lib32/libX11-xcb.so /usr/lib32/libxcb-render.so /usr/lib32/libXrender.so /usr/lib32/libX11.so /usr/lib32/libxcb.so /usr/lib32/libXau.so /usr/lib32/libXdmcp.so -lGL -lOpenVG /usr/lib32/libgdk_pixbuf-2.0.so /usr/lib32/libgio-2.0.so -lresolv /usr/lib32/libpangoft2-1.0.so /usr/lib32/libpango-1.0.so -lm /usr/lib32/libfreetype.so -lz -lfontconfig /usr/lib32/libgobject-2.0.so /usr/lib32/libgmodule-2.0.so -ldl /usr/lib32/libgthread-2.0.so -lpthread /usr/lib32/libglib-2.0.so /usr/lib32/libiconv.so /usr/lib32/libpcre.so -lrt -m32 -march=i686 -mtune=generic -O2 -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 -pthread -Wl,-soname -Wl,im-xim.so -o .libs/im-xim.so
libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s "../im-xim.la" "im-xim.la" )
../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > gtk.immodules
Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel
/tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tmp/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel
make[3]: *** [gtk.immodules] Error 1
make[3]: Leaving directory `/tmp/gtk+/modules/input'
Indeed, even this fails :
$ LD_LIBRARY_PATH=../../gtk/.libs:../../gdk/.libs LD_PRELINK=../../gtk/.libs/libgtk-x11-2.0.so:../../gdk/.libs/libgdk-x11-2.0.so /tmp/gtk+/gtk/.libs/lt-gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > gtk.immodules
Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel
/tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tmp/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel
I think you need to be repeating the '-Wl,-rpath,/tmp/gtk+/gdk/.libs:/tmp/gtk+/gtk/.libs' also as: '-Wl,-rpath-link,/tmp/gtk+/gdk/.libs:/tmp/gtk+/gtk/.libs' , because some link module is linked
internally here to libgtk-x11-2.0.so , so the -rpath value is not used, just -rpath-link (unset) so /usr/lib32/libgtk-x11.2.0.so from the previous gtk+-2.0 version is picked up .
This problem does not occur with a native x86_64 build, because I do not need to set -rpath for such builds.
This is with toolchain :
$ eval {gcc,ld,/sbin/ldconfig,libtool,autoconf,automake}' --version; ' | grep '[(]G'
gcc (GCC) 4.6.0
GNU ld (GNU Binutils) 2.21.51.20110407
ldconfig (GNU libc) 2.13
libtool (GNU libtool 1.3332 2011-04-10) 2.4.1a
autoconf (GNU Autoconf) 2.68
automake (GNU automake) 1.11a
with all installed files unmodified from original installation .
NOTE : I think this bug is related to (but different from) bug #8537 :
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8537
While I've been using your excellent libtool script for years without probing to far into its implementation ,
I have noticed issues such as these crop up from time to time, and am finally resolved to do something about it -
I'll continue investigating and submit a patch to fix this if I find one .
All the best,
Jason
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8557; Package libtool.
(Tue, 26 Apr 2011 19:31:01 GMT) Full text and rfc822 format available.Message #8 received at 8557 <at> debbugs.gnu.org (full text, mbox):
From: Ingo Krabbe <ikrabbe.ask <at> gmail.com> To: Jason Vas Dias <jason.vas.dias <at> gmail.com> Cc: bug-libtool <at> gnu.org, 8557 <at> debbugs.gnu.org Subject: Re: bug#8557: libtool run against newly built libraries fails in setarch 'i686' Date: Tue, 26 Apr 2011 21:12:55 +0200
On Tue, Apr 26, 2011 at 11:37:11AM +0100, Jason Vas Dias wrote: > Hi - when running in a 32-bit environment on a native x86_64 linux host, > attempting to build gtk+-2.24.4 fails because libtool incorrectly links > a newly built executable to /usr/lib32/ libgdk-x11-2.0.so.0, not to > ../../gtk/.libs/libgdk-x11-2.0.so.0 : Hi Jason, I assume from what you tell us below > > ENVIRONMENT: > > I source this file to setup an i686 build environment in a 'setarch i686' shell instance : > > $ cat ~/32.bit.env > declare -x ARCH=i686 > declare -x AS="/usr/bin/as -32" > declare -x ASFLAGS="-Wa,-32" > declare -x CFLAGS="-march=i686 -mtune=generic -g -O2 -fPIC -DPIC -Wa,--compress-debug-sections" > declare -x LD="/usr/bin/ld -melf_i386" > declare -x 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" > declare -x PATH="/bin:/usr/bin:." > declare -x PKG_CONFIG_PATH="/usr/lib32/pkgconfig/" > > $ setarch i686 > $ . ~/32.bit.env > > And, trying to build gtk+2.0 (v 2.24.4 ) , it fails : > > > libtool: link: ( cd ".libs" && rm -f "im-viqr.la" && ln -s "../im-viqr.la" "im-viqr.la" ) > libtool: link: /usr/bin/gcc -m32 -shared -fPIC -DPIC .libs/gtkimcontextxim.o .libs/imxim.o -Wl,-rpath -Wl,/tmp/gtk+/gdk/.libs -Wl,-rpath -Wl,/tmp/gtk+/gtk/.libs -L/tmp/gtk+/gdk/.libs ../../gdk/.libs/libgdk-x11-2.0.so -L/usr/lib32 ../../gtk/.libs/libgtk-x11-2.0.so /tmp/gtk+/gdk/.libs/libgdk-x11-2.0.so /usr/lib32/libXinerama.so /usr/lib32/libXrandr.so -lXext /usr/lib32/libXcursor.so /usr/lib32/libpangocairo-1.0.so /usr/lib32/libXcomposite.so /usr/lib32/libXdamage.so /usr/lib32/libXfixes.so /usr/lib32/libatk-1.0.so /usr/lib32/libcairo.so /usr/lib32/libpixman-1.so -lEGL /usr/lib32/libpng15.so /usr/lib32/libxcb-dri2.so -ludev /usr/lib32/libxcb-shm.so /usr/lib32/libX11-xcb.so /usr/lib32/libxcb-render.so /usr/lib32/libXrender.so /usr/lib32/libX11.so /usr/lib32/libxcb.so /usr/lib32/libXau.so /usr/lib32/libXdmcp.so -lGL -lOpenVG /usr/lib32/libgdk_pixbuf-2.0.so /usr/lib32/libgio-2.0.so -lresolv /usr/lib32/libpangoft2-1.0.so /usr/lib32/libpango-1.0.so -lm /usr/lib32/libfreetype.so -lz -lfontconfig /usr/lib32/libgobject-2.0.so /usr/lib32/libgmodule-2.0.so -ldl /usr/lib32/libgthread-2.0.so -lpthread /usr/lib32/libglib-2.0.so /usr/lib32/libiconv.so /usr/lib32/libpcre.so -lrt -m32 -march=i686 -mtune=generic -O2 -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 -pthread -Wl,-soname -Wl,im-xim.so -o .libs/im-xim.so > libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s "../im-xim.la" "im-xim.la" ) > ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > gtk.immodules > Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel > /tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tmp/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel > make[3]: *** [gtk.immodules] Error 1 > make[3]: Leaving directory `/tmp/gtk+/modules/input' That the problem is not the link itself, but some flaw in the internal compilation of the LD_LIBRARY_PATH for temporary executables within the build tree: Here "../../gtk/gtk-query-immodules-2.0". This problem affects all exectuables libtool links and the build process uses them directly from the build tree, if some used libraries are a modified part of the build process themselves and if these library version are already installed with the same version: Here "libgtk-x11-2.0.so", which is installed and a modified version exists in "../../gtk/.libs", as I assume. You will notice that ../../gtk/gtk-query-immodules-2.0 is a script with an embedded LD_LIBRARY_PATH that points to /usr/lib32. > > Indeed, even this fails : > > $ LD_LIBRARY_PATH=../../gtk/.libs:../../gdk/.libs LD_PRELINK=../../gtk/.libs/libgtk-x11-2.0.so:../../gdk/.libs/libgdk-x11-2.0.so /tmp/gtk+/gtk/.libs/lt-gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > gtk.immodules > Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel > /tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tmp/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel This should work though. At least LD_LIBRARY_PATH=../../gtk/.libs ldd /tmp/gtk+/gtk/.libs/lt-gtk-query-immodules-2.0 should get you the correct list of libraries. Also try export LD_LIBRARY_PATH=../../gtk/.libs /tmp/gtk+/gtk/.libs/lt-gtk-query-immodules-2.0 im-am-et.la \ im-cedilla.la im-cyrillic-translit.la im-inuktitut.la im-ipa.la \ im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la \ im-xim.la or tune the embedded LD_LIBRARY_PATH in ../../gtk/gtk-query-immodules-2.0 > > I think you need to be repeating the '-Wl,-rpath,/tmp/gtk+/gdk/.libs:/tmp/gtk+/gtk/.libs' also as: '-Wl,-rpath-link,/tmp/gtk+/gdk/.libs:/tmp/gtk+/gtk/.libs' , because some link module is linked > internally here to libgtk-x11-2.0.so , so the -rpath value is not used, just -rpath-link (unset) so /usr/lib32/libgtk-x11.2.0.so from the previous gtk+-2.0 version is picked up . > > This problem does not occur with a native x86_64 build, because I do not need to set -rpath for such builds. I have posted some patch for this behaviour some time ago against libtool git source, that reorders the compiled LD_LIBRARY_PATH for the temporary executable scripts. bye ingo
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8557; Package libtool.
(Tue, 26 Apr 2011 19:40:03 GMT) Full text and rfc822 format available.owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8557; Package libtool.
(Wed, 27 Apr 2011 00:24:01 GMT) Full text and rfc822 format available.Message #14 received at 8557 <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: 8557 <at> debbugs.gnu.org Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la' files Date: Wed, 27 Apr 2011 01:22:58 +0100
On Tuesday 26 April 2011 17:56:22 Mike Frysinger wrote:
> On Tue, Apr 26, 2011 at 08:38, Jason Vas Dias wrote:
> > My 32-bit C++ libtool builds were failing because libtool incorrectly accessed
> > /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++v3.la ,
> > which gcc installs for its 64-bit environment, NOT
> > /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libstdc++v3.la ,
> > which gcc installs for its 64-bit environment.
>
> you mean which gcc installs for its 32-bit env
>
> > And I try to rebuild the 32-bit package from scratch, and it fails because libtool can
> > find no system 'libstdc++v3.la' file.
>
> most likely not a bug in libtool. something (probably a .la file) has
> encoded a reference to the libstdc++ .la file. find that something
> and fix it.
> -mike
>
> Hi Mike - thanks for responding !
> Actually , I can't find ANY references to 'stdc++*.la' under any /{,usr/}lib*/ directory :
> [ root <at> jvdspc:/ 00:23:51 1256:750 ]
> $ cd /; find lib32/ lib64/ usr/lib32/ usr/lib64/ -name '*.la' -a -type f | while read f; do egrep -Hn 'stdc\+\+[^.]+\.la' $f; done
OOPS: SORRY ! this should be ^'stdc\+\+[^.]*\.la'
So yes, those stdc++*.la references were bogus, sorry !
But my questions remain :
> [ root <at> jvdspc:/ 00:24:24 1257:751 ]
>
> But I see code in libtool that is looking translating a reference to '-lstdc++' into looking for (any dir in $sys_lib_search_path_spec)/stdc++.la .
>
> 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 ?
>
>If I change this line of libtool (GNU libtool 1.3332 2011-04-10) 2.4.1a 's
> installed /usr/bin/libtool :
>
># 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 "
>
>TO:
># 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}')"
>
>and remove wherever it says "-nostdlibs \$predep_objects" or
> "\$postdep_objects" from link command lines, then everything is hunky-dory
> !
>
>There is no bogus dependencies on any stdc++*.la generated either by the gtk
> build of bug #8557 either by that version, nor is there any glibc bug
> #12454 triggered by a poppler build as in bug #8537 .
>
>It seems to me that libtool is doing too much second-guessing of gcc's
> correct defaults on the Linux platform ; ie. specifying defaults for gcc
> (sometimes incorrectly!) that gcc would in any case get correct all on its
> own.
Please, Mike, why is libtool not using some form of dynamic setting of $sys_lib_search_path_spec from $CC and $CFLAGS ???
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8557; Package libtool.
(Wed, 27 Apr 2011 23:56:03 GMT) Full text and rfc822 format available.Message #17 received at 8557 <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
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8557; Package libtool.
(Thu, 28 Apr 2011 12:00:05 GMT) Full text and rfc822 format available.Message #20 received at 8557 <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
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8557; Package libtool.
(Thu, 28 Apr 2011 19:06:02 GMT) Full text and rfc822 format available.Message #23 received at 8557 <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
owner <at> debbugs.gnu.org, bug-libtool <at> gnu.org:bug#8557; Package libtool.
(Thu, 28 Apr 2011 21:59:02 GMT) Full text and rfc822 format available.Message #26 received at 8557 <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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.