After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 582982 - dev-util/glade-3.6.3: re-links to system's glade for python plugin
dev-util/glade-3.6.3: re-links to system's glade for python plugin
Status: RESOLVED FIXED
Product: glade
Classification: Applications
Component: bindings
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-17 20:59 UTC by Rafał Mużyło
Modified: 2009-06-12 23:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove PYTHON_LIBS from LDFLAGS (622 bytes, patch)
2009-06-07 08:05 UTC, Arun Raghavan
none Details | Review

Description Rafał Mużyło 2009-05-17 20:59:22 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.
Comment 1 Gilles Dartiguelongue 2009-05-17 21:39:30 UTC
CCing gentoo's gnome team for tracking purpose.
Comment 2 Tristan Van Berkom 2009-05-18 23:07:48 UTC
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.




Comment 3 Rafał Mużyło 2009-05-19 00:16:07 UTC
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.
Comment 4 Rafał Mużyło 2009-05-19 00:46:23 UTC
And what do you mean by:
"python.m4 is supplied by python" ?
It's neither in python tarball
nor in automake one.
Comment 5 Rafał Mużyło 2009-05-19 00:49:52 UTC
Unless that meant:
glade got it from pygtk.
Comment 6 Tristan Van Berkom 2009-05-19 15:45:06 UTC
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.
Comment 7 Tristan Van Berkom 2009-05-19 16:10:43 UTC
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.

Comment 8 Rafał Mużyło 2009-05-19 16:27:32 UTC
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'.
Comment 9 Tristan Van Berkom 2009-05-25 19:07:45 UTC
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...
Comment 10 Arun Raghavan 2009-06-01 20:06:11 UTC
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.
Comment 11 Daniel Macks 2009-06-06 21:06:45 UTC
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.
Comment 12 Tristan Van Berkom 2009-06-06 21:12:32 UTC
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 ?

Comment 13 Daniel Macks 2009-06-06 21:19:11 UTC
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.
Comment 14 Rafał Mużyło 2009-06-06 22:15:45 UTC
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.
Comment 15 Tristan Van Berkom 2009-06-06 23:38:21 UTC
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 ?
Comment 16 Rafał Mużyło 2009-06-07 00:54:06 UTC
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.
Comment 17 Gilles Dartiguelongue 2009-06-07 06:58:33 UTC
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.
Comment 18 Arun Raghavan 2009-06-07 07:28:48 UTC
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
Comment 19 Arun Raghavan 2009-06-07 08:05:38 UTC
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.
Comment 20 Tristan Van Berkom 2009-06-12 23:15:48 UTC
Ok committing, closing this one and hoping for the best :)

Thanks for all your help with this.