* 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. Stephen
Attachment:
signature.asc
Description: Digital signature