[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: Mike Frysinger
Subject: Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Date: Tue, 25 Aug 2009 21:08:00 -0400
User-agent: KMail/1.12.0 (Linux/; KDE/4.3.0; x86_64; ; )

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).  we want to avoid rpath's being 
encoded in binaries for system library paths.

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

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