Package: libtool;
View this message in rfc822 format
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: 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.