GNOME Bugzilla – Bug 582982
dev-util/glade-3.6.3: re-links to system's glade for python plugin
Last modified: 2009-06-12 23:15:48 UTC
Due to this construct in m4/python.m4: py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"` if test "x$PYTHON_LIBS" == x; then PYTHON_LIBS="-L${py_prefix}/lib -lpython${PYTHON_VERSION}" fi libgladepython.so gets relinked to system copy of libgladeui-1.so. That's incorrect. It breaks it, if a DESTDIR is used in 'make install' and you're upgrading from glade 3.4.5. See http://bugs.gentoo.org/show_bug.cgi?id=268236.
CCing gentoo's gnome team for tracking purpose.
According to plugins/python/Makefile.am, we are always linking to $(top_builddir)/gladeui/libgladeui-1.la, which should never be the system libgladeui. Also, python.m4 is not maintained by Glade, its disted in tarballs because autogen will pull in the m4s at build time, python.m4 is supplied by python and shouldnt tell us anything about where to get libgladeui. It is possible this is just a prefix screwup somehow ? i.e. Glade was built with the system prefix first (generating the offending libgladeui-1.la file) and then rebuilt into an optional prefix, but the linker still sees the bogus prefix in the libgladeui-1.la ? Well anyway, I read the bug, I dont think its a problem with the -L generated by the python.m4, the -L should be right about where to find python (not where to find libgladeui-1), furthermore, the -L on the link line should be of no consequence, since we specify the .la file directly in the compile line of libgladepython.so (there should be no linker search path for the lib, since there is no -lgladeui-1). Im pretty sure this is a matter of building in an unclean sandbox, polluted .la files and buggy libtool behavior as usual, if you want to send me an actual build log, I can take a look at it and try to guess what happened.
I think you're wrong here. The command that creates the problem during make install is: libtool: install: warning: relinking `libgladepython.la' (cd /var/tmp/portage/dev-util/glade-3.6.3/work/glade3-3.6.3/plugins/python; /bin/sh ../../libtool --tag=CC --mode=relink i686-pc-linux-gnu-gcc -O2 -march=athlon -mtune=athlon -pipe -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,relro -o libgladepython.la -rpath /usr/lib/glade3/modules -module -avoid-version -L/usr/lib -lpython2.6 libgladepython_la-glade-python.lo ../../gladeui/libgladeui-1.la -L/usr/lib -lpython2.6 -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lxml2 -inst-prefix-dir /var/tmp/portage/dev-util/glade-3.6.3/image/) i686-pc-linux-gnu-gcc -shared .libs/libgladepython_la-glade-python.o -L/usr/lib -L/var/tmp/portage/dev-util/glade-3.6.3/image//usr/lib -lgladeui-1 -lpython2.6 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lxml2 -march=athlon -mtune=athlon -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z -Wl,relro -pthread -Wl,-soname -Wl,libgladepython.so -o .libs/libgladepython.so The problem comes from the fact, that '-L/usr/lib' comes before '-L/var/tmp/portage/dev-util/glade-3.6.3/image//usr/lib', so /usr/lib is searched first and, as it's an upgrade, we're talking about, there's already libgladeui-1 there. As long, as major version didn't change, nobody simply noticed the problem. That '-L/usr/lib' comes from the above mentioned macro. If it was not there, it most probably would be linked properly.
And what do you mean by: "python.m4 is supplied by python" ? It's neither in python tarball nor in automake one.
Unless that meant: glade got it from pygtk.
Thanks for posting the build portion, from the Makefile.am its hard to tell that libtool will dig into the libgladeui-1.la and turn it into a -lgladeui-1. (In reply to comment #3) > I think you're wrong here. > The command that creates the problem during make install is: > libtool: install: warning: relinking `libgladepython.la' > (cd /var/tmp/portage/dev-util/glade-3.6.3/work/glade3-3.6.3/plugins/python; > /bin/sh ../../libtool --tag=CC --mode=relink i686-pc-linux-gnu-gcc -O2 > -march=athlon -mtune=athlon -pipe -Wl,-O1 -Wl,--as-needed -Wl,--sort-common > -Wl,-z,relro -o libgladepython.la -rpath /usr/lib/glade3/modules -module > -avoid-version -L/usr/lib -lpython2.6 libgladepython_la-glade-python.lo > ../../gladeui/libgladeui-1.la -L/usr/lib -lpython2.6 -pthread -lgtk-x11-2.0 > -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 > -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 > -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lxml2 -inst-prefix-dir > /var/tmp/portage/dev-util/glade-3.6.3/image/) > i686-pc-linux-gnu-gcc -shared .libs/libgladepython_la-glade-python.o > -L/usr/lib -L/var/tmp/portage/dev-util/glade-3.6.3/image//usr/lib -lgladeui-1 > -lpython2.6 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 > -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig > -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lxml2 -march=athlon > -mtune=athlon -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z -Wl,relro > -pthread -Wl,-soname -Wl,libgladepython.so -o .libs/libgladepython.so > > The problem comes from the fact, that '-L/usr/lib' comes before > '-L/var/tmp/portage/dev-util/glade-3.6.3/image//usr/lib', > so /usr/lib is searched first and, > as it's an upgrade, we're talking about, > there's already libgladeui-1 there. > As long, as major version didn't change, nobody simply noticed > the problem. > > That '-L/usr/lib' comes from the above mentioned macro. > If it was not there, it most probably would be linked properly. > Unfortunately I do not maintain this macro, but from the glance I cast yesterday - I think I could fix it from Makefile.am by putting the PYTHON_LIBS after all the other libs. Before I hazard a fix for this, do you think you could test it out for me and see if it works in your build system ? Basically, my theory is that this is the offending lines in plugins/python/Makefile.am: libgladepython_la_LDFLAGS = -module -avoid-version $(PYTHON_LIBS) $(AM_LDFLAGS) libgladepython_la_LIBADD = $(libgladeui) $(PYTHON_LIBS) I dont know why python is there twice to begin with, I would try just placing it after am_ldflags and removing it from libadd, or probably the opposite is the right way, remove it from flags all together and just put it in libadd at the end.
Damnit, I do maintain that file... gah let me find out why we have a committed python.m4, maybe the whole root of the problem is that we do have a macro, when we should be pulling the macro like we do all the other macros from their own packages/providers.
No, it's just the way libtool works. It's explicit vs implicit. Anything taken from ../../gladeui/libgladeui-1.la is implicit, so '-L/usr/lib', as it's explicit, will come before it, so it can override it, cause explicit values should override implicit ones. '-L/var/tmp/portage/dev-util/glade-3.6.3/image//usr/lib -lgladeui-1' comes from la file and will always be after '-L/usr/lib'.
Ok, so what can we do to fix this, from what I understand, the PKG_CHECK_MODULES (PYGTK, in configure.ac is unneeded, what we are after is the PYTHON_LIBS from python.m4 so we can link and run the interpretor from the plugin, which never needs to know about a pygtk class anyway (it should work with any python wrapped GObject). So, what I dont understand, is where is the $PYTHON variable assigned for python.m4, and when *that* python is envoked and queried for a path, why doesnt it return the relocated exec path... also, Im not sure how autoconf files grok the DESTDIR, it would be my assumption that DESTDIR is an empty var provided by automake to allow you to relocate make install (i.e. destdir doesnt need substitutions so why mention it in the autoconf macro ?) Please, if someone knows what is the right way to correct this, or can shed some light, I need to push out this plugin hopefully with the next release and my guess is that this bug is blocking the distro maintainers...
The $PYTHON variable comes from AM_PATH_PYTHON, which is defined in aclocal.m4. As for getting PYTHON_LIBS, calling AM_CHECK_PYTHON_LIBS should be enough. However, I too am wit's end as to how to make the local version of the library take precedence.
Going back to Comment #6 and the repeated PYTHON_LIBS, the libtool call is >-L/usr/lib -lpython2.6 libgladepython_la-glade-python.lo > ../../gladeui/libgladeui-1.la -L/usr/lib -lpython2.6 is processed to give a linker call: > -L/usr/lib -L/var/tmp/portage/dev-util/glade-3.6.3/image//usr/lib -lgladeui-1 If -L/usr/lib is coming before local .la, makes some sense that libtool would call ld with -L/usr/lib before "however local .la is parsed". "Local before global" is always best-practice. Here's 3.6.4's Makefile.in: >libgladepython_la_LDFLAGS = -module -avoid-version $(PYTHON_LIBS) \ > $(AM_LDFLAGS) $(am__append_1) >libgladepython_la_LIBADD = $(libgladeui) $(PYTHON_LIBS) [...] >libgladepython.la: $(libgladepython_la_OBJECTS) $(libgladepython_la_DEPENDENCIES) > $(LINK) -rpath $(gladepythondir) $(libgladepython_la_LDFLAGS) >$(libgladepython_la_OBJECTS) $(libgladepython_la_LIBADD) $(LIBS) So it's clear that the early -L/usr/lib is coming from the PYTHON_LIBS in _LDFLAGS. Does removing it from there (and leaving it in _LIBADD) help? -libgladepython_la_LDFLAGS = -module -avoid-version $(PYTHON_LIBS) $(AM_LDFLAGS) +libgladepython_la_LDFLAGS = -module -avoid-version $(AM_LDFLAGS) That would be in keeping with automake's documentation, which states that _LIBADD is how dependent libraries should be passed.
It would be easy ofcourse for me to make the change, can the bug reporter please test this for me ? i.e. just removing PYTHON_LIBS from LDFLAGS since it is already in LIBADD and see if it links correctly ? For me to test this locally... I would have to build and install python into a relocated prefix, then rebuild glade into that prefix and then check ldd for system linkages correct ?
I cannot test this either: I'm on darwin, where libtool converts the local .la to the explicit path to the actual build-dir shared lib file rather than passing a build-dir -L and thus don't see the problem.
The real question seems to be more like: do we want to embed python (use its static lib), cause if we don't, that '-L/usr/lib' bit is redundant anyway. Though, yeah, removing PYTHON_LIBS from libgladepython_la_LDFLAGS may work. '-L${py_prefix}/lib' seems to be useful only if somebody installed python lib outside ld.so.conf, cause it doesn't look like it (the macro) would work even for a cross-compiling case.
When you compiling a bunch of packages generally isnt that the case ? i.e. your build host is building *everything* into a prefix, and the ld.so.conf doesnt know about that prefix - you need to be able to link in there without chrooting into the new sys root and creating an ld.so.conf right ? So, no we dont want to link a static python lib, but its my understanding that the -L${py_prefix}/lib is needed to link in -lpython-${version}, because when your compiling packages you definitly dont want to fallback on ld.so.conf, you want a strict link to the dynamic lib located in the preceding -L argument. Err, am I wrong ?
I must stress here, that I don't consider myself an expert in libtool internal mechanics (and would welcome an opinion of one here), but... IIRC, prefix stuff should be left to be handled by '--prefix' configure option - notice '-L/var/tmp/portage/dev-util/glade-3.6.3/image//usr/lib', that's ${DESTDIR}/${libdir}, where ${libdir} is, by default, ${exec_prefix}/lib, so if you are passing just prefix to configure, it should work anyway. It *may* be needed, if you put python in an unusual location, but I'm not sure, if that wouldn't break something else. Most of the stuff, I've seen, that needed more complicated stuff usually used explicit rpath, but here, it doesn't seem necessary.
prefix and other --xxxdir in autoconf are for defining where X or Y should be installed. If you want to make something build against a non-system library, you either need to use append its path to LD_PATH_LIBRARY or pass some mylib_LIBS and mylibs_CFLAGS as per configure --help or define --with-xxx and do some logic yourself. You can see here that the python macro doesn't allow to use the second method afaics because of the way it is written.
I did try pushing out the LDFLAGS bit but I got misled by the initial message (relinking ...). Here's the output (note that the -L/path/to/destdir/... is before -L/usr/lib - this should suffice for us, right?). libtool: install: warning: relinking `libgladepython.la' libtool: install: (cd /var/tmp/portage/dev-util/glade-3.6.3/work/glade3-3.6.3/plugins/python; /bin/sh /var/tmp/portage/dev-util/glade-3.6.3/work/glade3-3.6.3/libtool --tag CC --mode=relink i686-pc-linux-gnu-gcc -DG_LOG_DOMAIN=\"GladeUI-PYTHON\" -I../.. -I../.. -I/usr/include/python2.6 -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -Wall -Wnested-externs -Wpointer-arith -march=pentium-m -msse3 -O2 -pipe -g -module -avoid-version -Wl,--as-needed -o libgladepython.la -rpath /usr/lib/glade3/modules libgladepython_la-glade-python.lo ../../gladeui/libgladeui-1.la -L/usr/lib -lpython2.6 -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lxml2 -inst-prefix-dir /var/tmp/portage/dev-util/glade-3.6.3/image/) libtool: relink: i686-pc-linux-gnu-gcc -shared .libs/libgladepython_la-glade-python.o -L/var/tmp/portage/dev-util/glade-3.6.3/image//usr/lib -L/usr/lib -lgladeui-1 -lpython2.6 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lgio-2.0 -lpangocairo-1.0 -lpangoft2-1.0 -lcairo -lpixman-1 -lglitz-glx -lXmu -lXt -lSM -lICE -luuid -lXi -lGL -lXext -lglitz -lpng12 -lXrender -lX11 -lXau -lXdmcp -lpango-1.0 -lfontconfig -lfreetype -lexpat -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lrt -lglib-2.0 -lxml2 -ldl -lz -lm -pthread -march=pentium-m -msse3 -Wl,--as-needed -pthread -pthread -Wl,-soname -Wl,libgladepython.so -o .libs/libgladepython.so
Created attachment 136080 [details] [review] Remove PYTHON_LIBS from LDFLAGS I've verified that this works. Reinstalling glade-3.4.5, then upgrading back to 3.6.3 does not cause 3.6.3 to link to the old libgladeui (the package manager tracks this). So I think the fix is good to go. Attaching a patch for reference.
Ok committing, closing this one and hoping for the best :) Thanks for all your help with this.