libtool
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]