libtool
[Top][All Lists]
Advanced

[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 15:16:39 -0400
User-agent: KMail/1.12.0 (Linux/2.6.30.4; KDE/4.3.0; x86_64; ; )

On Tuesday 25 August 2009 13:50:18 address@hidden wrote:
> Mike wrote:
> > On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote:
> >> On Tue, 25 Aug 2009, Mike Frysinger wrote:
> >> >> Relying on the OS's implicit dependency features seems to be an
> >> >> approach which is fraught with peril.
> >> >
> >> > why ?
> >>
> >> When viewing the issue through Linux package-maintainer spectacles
> >> everything looks pretty straightforward since the environment and
> >> packages are well managed and tested prior to deployment.  Any
> >> failures can be usefully corrected.  Libraries are carefully built
> >> with well-managed partial dependency lists.  If you consider the case
> >> where someone installs and builds everything from a random collection
> >> of source packages on a random Linux release, then the situation is
> >> different.
> >>
> >> This issue has some up oodles of times.  Obviously there is a good
> >> reason for the complaints (Linux equivalent of "DLL hell") but the
> >> solution in libtool needs to be assured to work everywhere, and not
> >> just on well-managed well-manicured recent Linux.
> >
> > the "dll hell" issue you refer to really doesnt have much (anything?) to
> > do
> > with libtool.  that's a binary package issue.
> >
> > making the code use reduced library sets for only linux targets is fine
> > by me.
> > libtool already has plenty of target-specific code based on the quality
> > of library handling.
>
> I think the scope of the problem is more devious than you imagine.
>
> Example:
> - install libA to /odd/lib/libA.so
> - configure libB with /odd/lib/libA.so
> - install libB to /odd/usr/lib/libB.so
> - configure App with libB in /odd/usr/lib/libB.so
> - compilation of App fails since the linker can't find libA.so
>
> Libtool's dependency lists would have told the linker where libA was
> installed.  Many people follow this sort of pattern on shared filesystems.

having libtool process the libdir= fields and add appropriate -rpath-link 
options is trivial to do.  that doesnt mean every library in the dependency 
list should be added to the final linking step.
-mike

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


reply via email to

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