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

Re: Does dpkg-cross need to support static linking?


> > 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.


> 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. :)


Reply to: