[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Linking binaries against libtool libraries and non-libtool libraries
From: |
Christopher Sean Morrison |
Subject: |
Linking binaries against libtool libraries and non-libtool libraries |
Date: |
Sat, 22 Jan 2011 22:40:24 -0500 |
Compiling an application against libtool and non-libtool libraries seems to
result in a binary that works fine once installed, but will not execute
correctly when run through the libtool wrapper script prior to being installed.
The application fails to add the non-libtool library path to the list of
searched paths so the application ends up pulling a system-installed version of
the non-libtool library (which is run-time incompatible).
How can the path be specified [0] such that it'll run and find the correct
library prior to installation?
Specifying -rpath and -R as LDFLAGS seems to have no affect. Manually setting
'temp_rpath' in the libtool script during configure [1] does work, but is
clearly a non-optimal solution. The build-time library directories are
specified with -L during linking, so I would expect those paths to also be
searched in the wrapper script's [DY]LD_LIBRARY_PATH. Perhaps the -L
directories could also be added to the pre-installation library search paths.
Cheers!
Sean
[0] Ideally, looking for a solution that'll work with the stock libtool 2.2.4
on Mac OS X 10.6 for release management purposes.
[1] If temp_rpath is set to multiple colon-separated paths without a trailing
':', the resulting library path will be wrong due to the "colon-less"
concatenation with the value of shlibpath_var in func_emit_wrapper(). I'd
consider that concatenation without a ':' to be a bug if it weren't for the
undocumented use.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Linking binaries against libtool libraries and non-libtool libraries,
Christopher Sean Morrison <=