On Fri, Nov 09, 2012 at 07:12:10AM -0800, Dan Nicholson wrote: > On Nov 8, 2012 6:38 PM, "Poor Yorick" <org.gnu.lists.libt...@pooryorick.com> > 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