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

[Mike Frysinger]

On Tuesday 25 August 2009 18:41:52 Russ Allbery wrote:
> Bob Friesenhahn <address@hidden> writes:
> > How would you like to deal with the case where a library has multiple
> > usable dependencies, which satisify identical purposes, but via
> > different possible libraries?
> >
> >                          libfoo-ssl_fast.so
> >   myprog --> somelib -->     or
> >                          libfoo-ssl_slow.so
> >
> > Note that in this case myprog depends on somelib and so that is an
> > explicit dependency.  However somelib needs some symbols from a library
> > that the user selects at link time.
>
> In this one particular case, an explicit dependency seems reasonable.
>
> This case is exceptionally rare.  In all the years that I've worked on
> free software and packaging of software for multiple different versions of
> UNIX, I've never wanted to do this, and I don't know of any case in the
> thousands of packages in Debian where this technique is used.  Normally
> it's easier and more robust to just build two different versions of
> somelib, one for each of the alternative dependency libraries.  (See, for
> instance, how cURL is handled in Debian.)

i dont really see how this case is related to the discussion at hand.  if a 
library maker wanted to let people pick a provider, then the dependency 
wouldnt be expressed in the libtool linker script.  whether libtool processes 
all of the libraries in the linker script is irrelevant to this issue.

the termcap library is the only real world example ive seen, but Debian and 
pretty much every distro that matters forces ncurses everywhere.  you can see 
this with really old distros where readline never linked with a termcap 
provider -- packages that wanted to use readline had to select the library 
itself.  that's why you'll some configure scripts that try -lreadline and if 
that fails, does a search with like -lncurses, -lcurses, and -ltermcap.
-mike

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