[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bad LD_LIBRARY_PATH set in the libtool wrapper

From: Sam Varshavchik
Subject: Bad LD_LIBRARY_PATH set in the libtool wrapper
Date: Mon, 26 Dec 2011 15:06:22 -0500

My source tree builds two libraries, from two separate directories in the source tree. gets linked against in a different directory, as well as some system libraries in /usr/local/lib. declares thusly:

libxtls_la_LDFLAGS=-version-info 1 $(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthread

These macros expand to a search path that includes /usr/local/lib. In I end up with this (leaving out some unrelated stuff):

dependency_libs="-R/usr/local/lib -L/usr/local/lib [SOURCETREEPATH]/base/"

I then build an executable named "testuseragent_shared" that gets linked against


From this, libtool produces a wrapper for testuseragent_shared in the source
tree, that reads as follows (linewrapped):

The search path places /usr/local/lib ahead of …/base/.libs, for It obviously gets it from libxtls_la_LDFLAGS.

The problem here is when I already have a previously installed, older build in /usr/local/lib, and I run testuseragent_shared from the source tree, it ends up loading the older from /usr/local/lib, rather than the one that also gets built in the source tree. Hilarity ensues.

Yes, I know about -static, and I also produce a testuseragent_static linked with -static, that works splendidly from the source tree. But I'd really like to have a dynamically-linked testuseragent_shared and run it from the source tree, with the wrapper's help, for regression testing purposes.

I must be doing something fundamentally wrong here, but I can't figure it out. The more I think about it, the more I'm leaning towards thinking that libtool should always put source tree paths ahead of any system paths, in the wrapper. This is libtool 2.4.

Attachment: pgpDQVfUkbXjW.pgp
Description: PGP signature

reply via email to

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