On Tue, 30 Jun 2020 at 10:51:39 +0200, Chris Hofstaedtler wrote:
> I'm not sure it was a good idea before. Is static linking something
> you actively want to support for glib?
It has worked in the past, Policy says the static library "is usually
provided", and we occasionally get bug reports from people who want to
link random libraries statically, so I didn't feel comfortable with
unilaterally disabling it for no particular reason. The autopkgtest
is there partly because things we don't test usually don't work, and
partly because static linking to libmount regressed during GLib's move
from Autotools to Meson (the pkg-config metadata in GLib was wrong);
I added it to confirm that the regression fix had been effective.
If I'm disabling the static library because dependencies no longer
support it, then I can redirect bug reporters to the dependency and
let them argue their case there if they want to (as with libdbus, which
can't be linked statically any more due to libsystemd).
People occasionally try to change Policy to say that static equivalents
of shared libraries are definitely optional, or even that they are
discouraged, but this never reaches consensus, because someone always
appears and says "well actually, I rely on Debian shipping shared libfoo
and libbar for armhf so that I can statically link them into a binary
for my embedded frobnicator device, which
(has glibc from 2005|doesn't have glibc|doesn't have space for glibc|...)".
The obvious counterpoint that solving this is not really Debian's job
is rarely effective.
It is technically possible to link just the top of a dependency stack
statically (for example a GLib program with static GLib and libmount,
but dynamic libcryptsetup and glibc), but pkg-config doesn't make this
straightforward and in practice it requires hard-coding paths to static
libraries, so the autopkgtest in GLib doesn't attempt to exercise this.
smcv
