Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
bluca at debian.org
Wed Jul 1 16:21:12 BST 2020
On Tue, 30 Jun 2020 12:12:34 +0200 Chris Hofstaedtler <zeha at debian.org>
> * Simon McVittie <smcv at 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).
> Feel free to point people at libmount/src:util-linux.
> I'll see about removing libmount's static library in the -dev
> > 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!
Note that with this change:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: This is a digitally signed message part
More information about the pkg-gnome-maintainers