Hi, > > Missing .la files makes static linking somewhat more difficult, but it > > was never guaranteed that -dev packages pull in the -dev packages for > > all libraries used by them (ideally, they'd not reexport others' > > ABI/API and thus not require a dependency at all)
On Sun, May 02, 2010 at 02:40:18PM +0100, Neil Williams wrote: > Several of my own upstream packages explicitly need to export symbols > from another API within their own - otherwise it means suspect pointer > casts, unreliable and buggy API's and pointless code churn. e.g. if > libfoo uses libglib2.0 to provide hash table support, it is pointless > telling libfoo maintainers that the API cannot return a pointer to a > particular GHashTable but should cast it to a void pointer instead. Or > if libfoo manages incoming data into a GList, there's no point requiring > a callback API when what is needed is the GList. That way lies madness. Indeed -- but that case is problematic for another reason. I'm talking about the case where a library uses GList internally, but doesn't expose this via the API. With dynamic linking, you don't need to list glib on the linker command line, with static linking, you do. If the dependent library's ABI were exposed, then in principle your library would need to incorporate glib's SONAME into your own, and the application would very likely have to link against glib as well in order to interpret the data structures passed to it (while in practice noone does that as the runtime linker silently fixes this up and no one (except for libapt-pkg maintainers) can actually be bothered to use a correct SONAME, leading to interesting transitions during the release phase is another issue). > >, so when linking > > statically, I need to be aware of the full dependency chain either > > way. > Keeping the .a isn't a problem because it only needs to be moved, not > modified. If `pkg-config --static` is enough to make .a files useful, > let's keep them. Excellent. > So if even people who do want statically linked cross-built packages > don't want the .la files, I'm thinking that dpkg-cross should simply > drop them. "Don't want" is too harsh -- I have never found that I need them for anything, and I'm a bit of a traditionalist. :) > However, I'm not sure if dpkg-cross can prejudge the removal of the .la > files in Debian - or whether we simply need to be aware that .la files > are disappearing in due course. Either way has advantages and disadvantages. If we remove .la files, we get to keep the pieces if something breaks, but Debian may profit from the early warning. :) Simon -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
