Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

[dherring]

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.

Later,
Daniel