[Top][All Lists]

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

Re: removal of .la files from Debian and a possible solution to the libt

From: Anssi Hannula
Subject: Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Date: Wed, 26 Aug 2009 04:13:35 +0300
User-agent: Thunderbird (X11/20090815)

Mike Frysinger wrote:
> On Tuesday 25 August 2009 20:33:25 Anssi Hannula wrote:
>> Mike Frysinger wrote:
>>> On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote:
>>>> On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote:
>>>>> * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST:
>>>>>> On Tue, 25 Aug 2009, Anssi Hannula wrote:
>>>>>>> I think the proper way to solve this is to not link to
>>>>>>> dependency_libs when linking dynamically on systems where it is not
>>>>>>> needed to link to those. I haven't seen any correctly working patches
>>>>>>> that implement this.
>>>>>> Relying on the OS's implicit dependency features seems to be an
>>>>>> approach which is fraught with peril.
>>>>> With GNU/Linux, and libraries all being in directories searched by
>>>>> default by both the link editor and the runtime linker, the problems
>>>>> are fairly limited.  IIRC Debian requires that you link directly
>>>>> against all libraries that you require directly.
>>>>> The problems start as soon as you link (directly or indirectly) against
>>>>> libraries in directories not searched by default.  IOW: typically
>>>>> anything not provided by a properly packaged Debian package, installed
>>>>> by the user or the system maintainer.
>>>> Surely at least on Linux the -rpath linker option would be a much better
>>>> way to solve this?
>>> a combo of -rpath and -rpath-link ...
>> Well, -rpath is already added by libtool when a dependency is not in the
>> standard library search path.
>> AFAICS -rpath-link would be useful if we want to be double-sure that it
>> works, e.g. in case RPATH of a library/app has been tampered with. I'm
>> not taking a stance on whether -rpath-link should be added or not, though.
> i'm thinking in terms of linker -rpath/-rpath-link, not libtool (i vaguely 
> recall they're similar but not the same).

So am I.

> we want to avoid rpath's being 
> encoded in binaries for system library paths.

Yes, we do. And as I said above, that is what libtool currently does. It
adds -rpath (the linker one) automatically, but only for non-system paths.

Anssi Hannula

reply via email to

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