[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8557: libtool run against newly built libraries fails in setarch 'i6
From: |
Ingo Krabbe |
Subject: |
bug#8557: libtool run against newly built libraries fails in setarch 'i686' |
Date: |
Tue, 26 Apr 2011 21:12:55 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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