GNOME Bugzilla – Bug 670152
g-ir-scanner depends on rpath (and breaks with --enable-new-dtags)
Last modified: 2015-02-07 16:52:32 UTC
Every now and then you see jhbuild failures where you have missing symbols due to something in the buildtree trying to link against an installed copy of the library. The usual fix is to 'jhbuild uninstall' whatever it is and try again. We've been pretty good at figuring out the cause of these issues and stamping them out, but one remains in g-ir-scanner when the LDFLAGS contains --enable-new-dtags. Here's how you can reproduce it (to borrow on a recent example I hit): - get a git checkout of cogl - git checkout 8012eee31f01011d4b6572d924d7a979470c4afe^ - LDFLAGS='-Wl,--enable-new-dtags' ./autogen.sh --prefix=/some/where - make && make install then - git checkout 8012eee31f01011d4b6572d924d7a979470c4afe # one commit later - make This fails (for me at least). The original implementation of DT_RPATH was widely regarded to be a mistake because it has priority over LD_LIBRARY_PATH. DT_RUNPATH was introduced to solve this issue. If DT_RUNPATH is set (even if DT_RPATH is also set) then the linker gives precedence to LD_LIBRARY_PATH when searching for libraries. DT_RUNPATH is enabled by passing --enable-new-dtags to the linker. Unfortunately, the g-ir-scanner is depending on the broken DT_RPATH behaviour (namely that LD_LIBRARY_PATH gets ignored). We should probably fix this by having g-ir-scanner set the LD_LIBRARY_PATH before attempting to invoke the compiler. Better still would be to not try to link and run code as part of g-ir-scanner, but that's a story for another day...
This is really complicated. g-ir-scanner is correctly invoking libtool to make an executable. Notably, it is passing the in-tree .la file to libtool. I can't imagine what could be done better here. These are the exact commands (with V=1): /home/desrt/jhbuild/install/bin/g-ir-scanner --namespace=Cogl --nsversion=1.0 --libtool="/bin/bash ../libtool" --include=GL-1.0 --include=GObject-2.0 --pkg-export=cogl-1.0 --library=libcogl.la --warn-all --c-include='cogl/cogl.h' -I.. -I.. -I./tesselator -I./winsys -I./driver/ -DG_LOG_DOMAIN=\"Cogl\" -DCLUTTER_COMPILATION -DCOGL_GL_LIBNAME=\"libGL.so.1\" -DCOGL_GLES1_LIBNAME=\"\" -DCOGL_GLES2_LIBNAME=\"\" -DCOGL_LOCALEDIR=\""/home/desrt/local/share/locale"\" -pthread -I/home/desrt/jhbuild/install/include/cairo -I/home/desrt/jhbuild/install/include/glib-2.0 -I/home/desrt/jhbuild/install/lib/glib-2.0/include -I/home/desrt/jhbuild/install/include/pixman-1 -I/home/desrt/jhbuild/install/include -I/home/desrt/jhbuild/install/include/gdk-pixbuf-2.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm cogl-object.h cogl-bitmap.h cogl-buffer.h cogl-color.h cogl-fixed.h cogl-depth-state.h cogl-material-compat.h cogl-vector.h cogl-euler.h cogl-quaternion.h cogl-matrix.h cogl-offscreen.h cogl-primitives.h cogl-path.h cogl-pixel-buffer.h cogl-poll.h cogl-shader.h cogl-texture.h cogl-texture-3d.h cogl-texture-2d.h cogl-texture-rectangle.h cogl-texture-2d-sliced.h cogl-sub-texture.h cogl-meta-texture.h cogl-types.h cogl-vertex-buffer.h cogl-index-buffer.h cogl-attribute-buffer.h cogl-indices.h cogl-attribute.h cogl-primitive.h cogl-clip-state.h cogl-framebuffer.h cogl-onscreen.h cogl-clutter.h cogl.h cogl-glib-source.h cogl-clutter-xlib.h cogl-xlib-renderer.h cogl-enum-types.h libcogl.la Makefile --output Cogl-1.0.gir /home/desrt/code/cogl/cogl/cogl-meta-texture.h:174: syntax error, unexpected identifier in ' CoglPipelineWrapMode wrap_s,' at 'CoglPipelineWrapMode' /home/desrt/code/cogl/cogl/cogl-meta-texture.h:177: syntax error, unexpected VOID, expecting identifier or '(' or '*' in ' void *user_data);' at 'void' /home/desrt/code/cogl/cogl/cogl-meta-texture.h:177: syntax error, unexpected ')', expecting ',' or ';' in ' void *user_data);' at ')' g-ir-scanner: compile: gcc -Wall -pthread -I/home/desrt/jhbuild/install/include/glib-2.0 -I/home/desrt/jhbuild/install/lib/glib-2.0/include -I.. -I.. -I./tesselator -I./winsys -I./driver/ -I/home/desrt/jhbuild/install/include/cairo -I/home/desrt/jhbuild/install/include/glib-2.0 -I/home/desrt/jhbuild/install/lib/glib-2.0/include -I/home/desrt/jhbuild/install/include/pixman-1 -I/home/desrt/jhbuild/install/include -I/home/desrt/jhbuild/install/include/gdk-pixbuf-2.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm -I/home/desrt/jhbuild/install/include/glib-2.0 -I/home/desrt/jhbuild/install/lib/glib-2.0/include -c -o /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/Cogl-1.0.o /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/Cogl-1.0.c g-ir-scanner: link: /bin/bash ../libtool --mode=link --tag=CC gcc -o /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/Cogl-1.0 -export-dynamic /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/Cogl-1.0.o -L. libcogl.la -pthread -Wl,--export-dynamic -L/home/desrt/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lrt -lglib-2.0 libtool: link: gcc -o /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/.libs/Cogl-1.0 /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/Cogl-1.0.o -pthread -Wl,--export-dynamic -Wl,--export-dynamic -L. ./.libs/libcogl.so -L/home/desrt/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lrt -lglib-2.0 -pthread -Wl,-rpath -Wl,/home/desrt/local/lib /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/.libs/Cogl-1.0: symbol lookup error: /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/.libs/Cogl-1.0: undefined symbol: cogl_texture_type_get_type Command '['/home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/Cogl-1.0', '--introspect-dump=/home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/functions.txt,/home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/dump.xml']' returned non-zero exit status 127 The output file /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/Cogl-1.0 is actually a libtool wrapper executable. Picking this file apart, one can see the following: LD_LIBRARY_PATH="/home/desrt/code/cogl/cogl/.libs:$LD_LIBRARY_PATH" which is exactly what should be happening. However, if you look at /home/desrt/code/cogl/cogl/tmp-introspectNSRjKl/.libs/Cogl-1.0 (the real binary) you see that it has an rpath set on it to the 'installed' location. That overrides the LD_LIBRARY_PATH that libtool so carefully set for itself. Of course this is the result of -Wl,-rpath -Wl,/home/desrt/local/lib on the linker command-line. I have no idea why libtool is electing to set the installed location rpath for a binary that is linked against the in-tree library.
So the one thing that g-ir-scanner is not passing to libtool is the -Wl,--enable-new-dtags given in the LDFLAGS. If that is passed in then everything works properly (because we end up with DT_RUNPATH on the produced binary). I guess libtool is somewhat reasonable to expect that LDFLAGS will be given consistently. So I guess the bug here is that g-ir-scanner is not passing the specified LDFLAGS through to the linker correctly.
(In reply to comment #2) > So the one thing that g-ir-scanner is not passing to libtool is the > -Wl,--enable-new-dtags given in the LDFLAGS. If that is passed in then > everything works properly (because we end up with DT_RUNPATH on the produced > binary). I guess libtool is somewhat reasonable to expect that LDFLAGS will be > given consistently. > > So I guess the bug here is that g-ir-scanner is not passing the specified > LDFLAGS through to the linker correctly. There's already code for: cflags = os.environ.get('CFLAGS') No opposition from me to adding LDFLAGS too. However - this section of code is a huge trigger for regressions. Let's be very careful adding to it.
IIRC, we don't do any kind of filtering of the CFLAGS, they are passed verbatim to the CC executable set. Makes sense to do the same with LDFLAGS, it will hopefully not break anything.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]