On Tue, 30 Jun 2020 12:12:34 +0200 Chris Hofstaedtler <z...@debian.org> wrote: > * Simon McVittie <s...@debian.org> [200630 11:23]: > > 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). > > Understood. > > Feel free to point people at libmount/src:util-linux. > > I'll see about removing libmount's static library in the -dev > package. > > > 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. > > Thanks for the explanation! > > Best, > Chris
Hi, Note that with this change: https://github.com/karelzak/util-linux/pull/1084 we'll be able to use dlopen instead of linking, so the current problem will go away. The broader issue of availability of static libraries down the stack is a different matter of course - if it doesn't happen for this, it will happen for something else and so on. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
