Might be easier just to forward this thread than to try to describe the
essence of the bug myself.
-------- Original Message --------
On 11/3/09 4:03 PM, Tim Mooney wrote:
> In regard to: Re: Running into cross-compilation issues with libtool
>> On 10/30/2009 01:53 PM, Nick Bowler wrote:
>>> On 13:19 Fri 30 Oct , Philip A. Prindeville wrote:
>>>> The problem is that this is an early linkage on the build host, where
>>>> the eventual DESTDIR hasn't yet been specified, but the resultant
>>>> libusbpp.la ends up looking like:
>>> I suspect that you have two libtool libraries in the same source tree,
>>> with one linked against the other. Chances are, the compiled binaries
>>> in the .libs directory are perfectly fine, and libtool is destroying
>>> them when you run 'make DESTDIR=/path/to/staging/dir install'.
>>> So we have libfoo.la and libbar.la, libbar links with libfoo and.
>>> Furthermore, you have a version of libfoo already installed on the host
>>> system, in /usr/lib. You cross-compile the package, using
>>> --prefix=/usr/lib (since that is where it will finally end up).
>>> Then you do 'make DESTDIR=/path/to/staging/dir install', and libtool
>>> decides to re-link the libraries against the libraries in the final
>>> installed location. In this case, it is /usr/lib. The problem is that
>>> the libfoo in /usr/lib is the wrong one, since the cross-compiled
>>> never got installed there!
>>> The workaround here is to manually copy the libraries from .libs into
>>> your staging directory. IMHO the fix is to make libtool not re-link
>>> anything if DESTDIR is set -- correct me if I'm wrong, but it seems to
>>> me that the current behaviour cannot possibly be correct on any
>>> platform, even on the ones that require re-linking.
>> That sounds about right, actually.
> Nick *is* right, at least about the scenario that triggers the problem.
> I've observed this behavior and asked about it on the list in the past.
> I run into this problem on a regular basis when building software for
> packaging on Solaris (not cross-compiling, just installing into DESTDIR
> for packaging).
> I'm not certain if skipping the relink if DESTDIR is being used is the
> fix for all platforms. My guess was that libtool's -inst-prefix-dir
> option needs to be augmented so that it correctly re-links against the
> library that it just installed in DESTDIR even though the .la file it
> will generate should *not* include the DESTDIR part of any paths (it
> should have the final destination, not the temporary area used for
> This problem has been with libtool since the -inst-prefix-dir option was
> added, which I believe happened early in the 1.5.x series.
Just saw this after posting another message.
Can someone file a bug against this and hopefully find a patch we can apply?