[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wrong LD_LIBRARY_PATH in wrapper scripts
From: |
Poor Yorick |
Subject: |
Re: wrong LD_LIBRARY_PATH in wrapper scripts |
Date: |
Fri, 9 Nov 2012 13:03:51 -0600 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Nov 09, 2012 at 07:12:10AM -0800, Dan Nicholson wrote:
> On Nov 8, 2012 6:38 PM, "Poor Yorick" <address@hidden>
> 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