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

Re: SUMMARY: Re: shared library -dev package naming proposal

* Junichi Uekawa (dancer@netfort.gr.jp) wrote:
> > - Option 4 (requires volunteers): fix libtool
> Blankly stating that libtool needs to be 'fixed'
> because it is 'broken' is not very helpful.
> Would you care to explain what needs to be fixed and why 
> it is broken?  Good working examples would be good.

One of the issues associated with just dropped .la files was that
libtool apparently doesn't handle having a .la file go missing in the
middle of a dependency chain.

ie: libfoo is built against libbar, both using libtool and both having
.la files.  libbar's .la file is then removed.  If you try to build
libxyz against libfoo, libtool will break because libfoo's .la says
libbar should have a .la but it doesn't.

Making libtool handle the missing .la file case for shared linking (at
least) would drop the requirement that -dev packages depend on -dev
packages when building shared libraries.  On Debian, at least, the .la
files generally shouldn't be necessary unless you're doing static
building.  Even then I don't think they're actually necessary until you
get up to the application that you want to build statically.  That is to
say, you shouldn't need them to build a static version of your library
unless you also build into that .a all the other libraries your library
depends on, and that's certainly not something we'd want to do.

> The following are background informations, please do comment
> if you find something is wrong about these:
> libnewt is an example library that requires libslang.
> The names are just symbollic; they just represent
> random library.
> fact 1: shared library 
>   gcc -lnewt a.c
> should work, since slang dependency is declared in NEEDED field
> of libnewt.so, which the link will be resolved at run-time.
> fact 2: static library
>   gcc -lslang -lnewt a.c
> is required for static lib linking, since .a files do not have
> dependency information, and symbols need to be resolved at link time.
> fact 3: libtool library
> libtool tries to implement a wrapper around shared library and 
> static library, so that both of them can be uniformly processed,
> and allows specifying just:
>   libtool cc -lnewt a.c
> (implementation detail: .la files contain the dependency 
> information for .a).

The issue here is that libtool doesn't need the .la files when doing
shared linking, but it breaks if it's not there when another .la file
said it should be.

> Debian implementation:
> Packages Build-Depend on -dev packages they directly require,
> thus a package requiring newt will Build-Depend on libnewt-dev,
> but not libslang2-dev.
> libnewt-dev will need to Depend on libslang2-dev, or
> static lib compilation with libtool will break.

This isn't actually the problem, if only static lib compilation broke I
don't think people would actually care all that much.  The problem is
that *shared* library compilation with libtool breaks, which is a
problem with libtool.


Attachment: signature.asc
Description: Digital signature

Reply to: