[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.


[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.

reply via email to

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