wrong LD_LIBRARY_PATH in wrapper scripts
Hi, Attempting to build glib-2.32.4, the "make check" stage, produces this result: /path/to/src/glib-2.32.4/glib-2.32.4/gobject/tests/.libs/boxed: symbol lookup error: /path/to/glib-2.32.4/glib-2.32.4/gobject/.libs/libgobject-2.0.so.0: undefined symbol: g_key_file_unref looking at .../gobject/test/boxed, which is a libtoolw wrapper, I see LD_LIBRARY_PATH="/path/to/src/glib-2.32.4/glib-2.32.4/gobject/.libs:/path/to/src/glib-2.32.4/glib-2.32.4/gthread/.libs:/path/to/software/collection/lib:/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs:$LD_LIBRARY_PATH" The problem here is that "/path/to/software/collection/lib" comes prior to "/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs", so the runtime linker is picking up /path/co/software/collection/lib/libglib-2.0.so instead of /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs/libglib-2.0.so. I presume that libtool inserted all three of the ".libs" paths, but don't see why it inserted two of them before "/path/to/software/collection/lib", and one after. .../gobject/tests/Makefile has this: boxed_DEPENDENCIES = ../libgobject-2.0.la \ $(top_builddir)/gthread/libgthread-2.0.la \ $(top_builddir)/glib/libglib-2.0.la /path/to/software/collection/lib exists both in the configuring environments LD_LIBRARY_PATH variable, as well as in the LDFLAGS variable. I've tried prepending "-L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs" to the LDFLAGS variable, with the same results. I'm asking on this list rather than the glib list because I'd like to understand in general what the issue might be and how to use libtool correctly in order not to have this kind of issue. How should I go about making sure that "/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs" has the proper precedence in LD_LIBRARY_PATH in the wrapper scripts? -- Yorick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: wrong LD_LIBRARY_PATH in wrapper scripts
On Fri, Nov 09, 2012 at 07:12:10AM -0800, Dan Nicholson wrote: > On Nov 8, 2012 6:38 PM, "Poor Yorick" > wrote: > > > > Hi, > > > > Attempting to build glib-2.32.4, the "make check" stage, produces this > result: > > > > /path/to/src/glib-2.32.4/glib-2.32.4/gobject/tests/.libs/boxed: symbol > lookup error: > /path/to/glib-2.32.4/glib-2.32.4/gobject/.libs/libgobject-2.0.so.0: > undefined symbol: g_key_file_unref > > > > looking at .../gobject/test/boxed, which is a libtoolw wrapper, I see > > > > > LD_LIBRARY_PATH="/path/to/src/glib-2.32.4/glib-2.32.4/gobject/.libs:/path/to/src/glib-2.32.4/glib-2.32.4/gthread/.libs:/path/to/software/collection/lib:/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs:$LD_LIBRARY_PATH" > > > > The problem here is that "/path/to/software/collection/lib" comes prior > to "/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs", so the runtime linker > is picking up /path/co/software/collection/lib/libglib-2.0.so instead of > /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs/libglib-2.0.so. I presume > that libtool inserted all three of the ".libs" paths, but don't see why it > inserted two of them before "/path/to/software/collection/lib", and one > after. .../gobject/tests/Makefile has this: > > > > boxed_DEPENDENCIES = ../libgobject-2.0.la \ > > $(top_builddir)/gthread/libgthread-2.0.la \ > > $(top_builddir)/glib/libglib-2.0.la > > > > /path/to/software/collection/lib exists both in the configuring > environments > > LD_LIBRARY_PATH variable, as well as in the LDFLAGS variable. I've tried > > prepending "-L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs" to the > LDFLAGS > > variable, with the same results. > > If I had to guess, one of gthread's dependencies is in > /path/to/software/collection/lib, so libtool adds it when processing > libgthread.la. On the other hand, I think both gobject and gthread depend > on glib, so I'd expect libtool to add its srcdir path at the appropriate > spot. You may want to look at the deplibs in the .la files to see if that's > the case. Maybe attach all three .la files. > the culprit turns out to be "/path/to/software/collection/lib/libffi.la", which was included in "dependency_libs" of /path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject-2.0.la. If I remove that, the error disappears. Here's a libtool command (pwd=/path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject/tests) that creates a wrapper with the bad LD_LIBRARY_PATH: ../../libtool --tag=CC --mode=link gcc -m64 -g -O2 -Wall -L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs -o boxed boxed.o ../libgobject-2.0.la ../../gthread/libgthread-2.0.la ../../glib/libglib-2.0.la Now the question is how to systematically work around such problems? Editing any of the .la files doesn't seem right. Is there something I can add to my build environment or configuration options? -- Yorick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: wrong LD_LIBRARY_PATH in wrapper scripts
> > On Nov 8, 2012 6:38 PM, "Poor Yorick" [SNIP] > > the culprit turns out to be "/path/to/software/collection/lib/libffi.la", > which was included in "dependency_libs" of > /path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject-2.0.la. If I remove > that, the error disappears. > > Here's a libtool command > (pwd=/path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject/tests) that > creates a wrapper with the bad LD_LIBRARY_PATH: > > ../../libtool --tag=CC --mode=link gcc -m64 -g -O2 -Wall > -L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs -o boxed boxed.o > ../libgobject-2.0.la ../../gthread/libgthread-2.0.la ../../glib/libglib-2.0.la > > Now the question is how to systematically work around such problems? Editing > any of the .la files doesn't seem right. Is there something I can add to my > build environment or configuration options? > I tried various things to try to get libtool to do the right thing, but finally just made a symylink to libffi /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs, which convinced libtool not to add /path/to/software/collection/lib to the LD_LIBRARY_PATH in the wrappers scripts. I wish I could have found a less ughly hack, or even a good fix. Ref: http://bugzilla.gnome.org/show_bug.cgi?id=688054 -- Yorick ___ https://lists.gnu.org/mailman/listinfo/libtool
libtool and --enable-new-dtags
When building software which doesn't use libtool, but does use autoconf, adding "-Wl,-rpath,/path/to/lib -Wl,--enable-new-dtags" is usually sufficient to end up with a shared object that has a RUNPATH value. I haven't yet figured out a good consistent way to do this with libtool. A solution that doesn't involve modifying package Makefiles or autoconf files would be preferred. Is there a nice standard way to get libtool-enabled packages to build like this? ___ http://lists.gnu.org/mailman/listinfo/libtool
