libxtls.la gets linked against libx.la in a different directory, as well as some system libraries in /usr/local/lib. Makefile.am declares thusly:
libxtls_la_LIBADD=../base/libx.la libxtls_la_LDFLAGS=-version-info 1 $(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthreadThese macros expand to a search path that includes /usr/local/lib. In libxtls.la I end up with this (leaving out some unrelated stuff):
dependency_libs="-R/usr/local/lib -L/usr/local/lib [SOURCETREEPATH]/base/libx.la"
I then build an executable named "testuseragent_shared" that gets linked against libxtls.la:
testuseragent_shared_SOURCES=testuseragent.C testuseragent_shared_LDADD=libxtls.la
From this, libtool produces a wrapper for testuseragent_shared in the source
tree, that reads as follows (linewrapped):LD_LIBRARY_PATH="[CURRENTDIR]/.libs:/usr/local/lib: [SOURCETREEPATH]/base/.libs:$LD_LIBRARY_PATH"
The search path places /usr/local/lib ahead of …/base/.libs, for libx.so.1. It obviously gets it from libxtls_la_LDFLAGS.
The problem here is when I already have a previously installed, older libx.so.1 build in /usr/local/lib, and I run testuseragent_shared from the source tree, it ends up loading the older libx.so.1 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.
pgpj4qALO6AA6.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
