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. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
