bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Re: Running into cross-compilation issues with libtool (and autocon


From: Philip Prindeville
Subject: Fwd: Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12
Date: Sat, 10 Jul 2010 23:33:30 -0600
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

Might be easier just to forward this thread than to try to describe the essence of the bug myself.


-------- Original Message --------
Subject: Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12
Date: Sat, 10 Jul 2010 18:41:32 -0600
From: Philip Prindeville <address@hidden>
To: address@hidden


On 11/3/09 4:03 PM, Tim Mooney wrote:
> In regard to: Re: Running into cross-compilation issues with libtool 
> (and...:
>
>> 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 
>>> libfoo
>>> 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 
> right
> 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
> staging).
>
> 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.
>
> Tim

Just saw this after posting another message.

Can someone file a bug against this and hopefully find a patch we can apply?

Thanks,

-Philip


reply via email to

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