Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
On Mon, 06 Jul 2020 at 18:50:01 +0200, Chris Hofstaedtler wrote: > src:util-linux will drop most static libraries in the 2.35.2-8 upload. > Please change the glib2.0 autopkgtest (by dropping the static test) > to allow this. libmount support in glib2.0 is temporarily disabled as a workaround for the crashes, so you can go ahead with this whenever you want. I'll disable the test for static linking of at least GIO (which is the part that uses libmount) before re-enabling the libmount dependency. smcv
Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
Hi Simon, src:util-linux will drop most static libraries in the 2.35.2-8 upload. Please change the glib2.0 autopkgtest (by dropping the static test) to allow this. Many thanks, Chris
Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
On Tue, 30 Jun 2020 12:12:34 +0200 Chris Hofstaedtler wrote: > * Simon McVittie [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
Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
* Simon McVittie [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
Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
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
Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
* Simon McVittie [200629 01:16]: > On Sun, 28 Jun 2020 at 22:00:58 +0200, Chris Hofstaedtler wrote: > > the autopkgtest suite offers quite interesting behaviour: > > With an installed libcryptsetup-dev, ld fails with "cannot find > > -lcryptsetup". > ... > > I imagine this might be caused by libcryptsetup-dev not shipping an > > .a library. > > This means that GLib could previously be successfully statically linked > (and we had a test to prove it), and now it cannot. > > Do you consider this to be a deliberate change? Is statically linking > a library that depends on libmount no longer supported? I'm not sure it was a good idea before. Is static linking something you actively want to support for glib? For libmount, if we want to support verity, this appears to be out of the question -- libcryptsetup will always make this impossible. While turning off verity will give us temporarily a libmount that can be statically linked again, I can imagine future changes pulling in libdevice-mapper. Then we'll be in another static-binary-with-dlopen situation. Which wont't work, AFAIK. Might be hypothetical, but all this "low level" stuff is quite dynamic nowadays. > (If it is, then we might as well stop providing static libraries for > GLib too, and you might as well stop providing static libraries for > libmount.) (Indeed.) Chris
Processed: Re: Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
Processing control commands: > reassign -1 src:glib2.0,src:util-linux Bug #963933 [src:glib2.0] glib2.0: autopkgtext: ld: cannot find -lcryptsetup Bug reassigned from package 'src:glib2.0' to 'src:glib2.0,src:util-linux'. No longer marked as found in versions glib2.0/2.64.3-1. Ignoring request to alter fixed versions of bug #963933 to the same values previously set > found -1 glib2.0/2.64.3-1 Bug #963933 [src:glib2.0,src:util-linux] glib2.0: autopkgtext: ld: cannot find -lcryptsetup Marked as found in versions glib2.0/2.64.3-1. > found -1 util-linux/2.35.2-5 Bug #963933 [src:glib2.0,src:util-linux] glib2.0: autopkgtext: ld: cannot find -lcryptsetup Marked as found in versions util-linux/2.35.2-5. > tags -1 + moreinfo bullseye sid Bug #963933 [src:glib2.0,src:util-linux] glib2.0: autopkgtext: ld: cannot find -lcryptsetup Added tag(s) sid, moreinfo, and bullseye. -- 963933: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963933 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
Control: reassign -1 src:glib2.0,src:util-linux Control: found -1 glib2.0/2.64.3-1 Control: found -1 util-linux/2.35.2-5 Control: tags -1 + moreinfo bullseye sid On Mon, 29 Jun 2020 at 00:16:49 +0100, Simon McVittie wrote: > On Sun, 28 Jun 2020 at 22:00:58 +0200, Chris Hofstaedtler wrote: > > I imagine this might be caused by libcryptsetup-dev not shipping an > > .a library. > > This means that GLib could previously be successfully statically linked > (and we had a test to prove it), and now it cannot. > > Do you consider this to be a deliberate change? Is statically linking > a library that depends on libmount no longer supported? This is either a regression in libmount (could be statically linked, now can't) or a wrong assumption in GLib (assumed that statically linking was supported, but (now?) it isn't). Which one? Thanks, smcv
Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
On Sun, 28 Jun 2020 at 22:00:58 +0200, Chris Hofstaedtler wrote: > the autopkgtest suite offers quite interesting behaviour: > With an installed libcryptsetup-dev, ld fails with "cannot find > -lcryptsetup". ... > I imagine this might be caused by libcryptsetup-dev not shipping an > .a library. This means that GLib could previously be successfully statically linked (and we had a test to prove it), and now it cannot. Do you consider this to be a deliberate change? Is statically linking a library that depends on libmount no longer supported? (If it is, then we might as well stop providing static libraries for GLib too, and you might as well stop providing static libraries for libmount.) smcv
Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup
Source: glib2.0 Severity: serious Version: 2.64.3-1 Dear glib2.0 Maintainers, the autopkgtest suite offers quite interesting behaviour: With an installed libcryptsetup-dev, ld fails with "cannot find -lcryptsetup". Log: https://ci.debian.net/data/autopkgtest/testing/amd64/g/glib2.0/6071882/log.gz autopkgtest [00:19:30]: test build: preparing testbed .. Selecting previously unselected package libcryptsetup-dev:amd64. Preparing to unpack .../19-libcryptsetup-dev_2%3a2.3.3-1_amd64.deb ... Unpacking libcryptsetup-dev:amd64 (2:2.3.3-1) ... .. autopkgtest [00:19:45]: test build: ---] autopkgtest [00:19:45]: test build: - - - - - - - - - - results - - - - - - - - - - buildPASS (superficial) autopkgtest [00:19:45]: test build-static: preparing testbed .. + gcc -static -o gio-static gio.c -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -lgio-2.0 -ldl -pthread -lresolv -lgmodule-2.0 -pthread -ldl -lz -lmount -lblkid -lcryptsetup -lselinux -lsepol -lpcre2-8 -pthread -lgobject-2.0 -pthread -lffi -lglib-2.0 -pthread -lpcre -pthread /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgmodule-2.0.a(gmodule.c.o): in function `g_module_open': (.text+0x703): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: cannot find -lcryptsetup I imagine this might be caused by libcryptsetup-dev not shipping an .a library. This prevents libmount1/util-linux to transition. Please investigate and hopefully fix the problem at hand. Thanks, Chris
