Hey Guilhem On Sat, 2024-04-27 at 01:48 +0200, Guilhem Moulin wrote: > Even it weren't, libpthread wouldn't show up since src:argon2 from > bookworm > and later is built using glibc ≥2.34.
When argon2 builds, it uses -pthread ... not really sure what that does exactly, the manpage merely says it links against pthread, but statically? Dynamically? Anyway, when building it manually and even with -lpthread, it doesn't show up - just as you say. Tried now for an hour or so to make it show up (eventually gave up and filed #1069912). So you say it's a glibc thingy, that this doesn't show up anymore? > AFAICT the “if the ldd output includes > libpthread then run copy_libgcc()” logic from initramfs-tools is > mostly moot > now, see https://bugs.debian.org/1032235#97 . Shouldn't initramfstools then not simply generally include libgcc? > We used the following workaround to manually call copy_libgcc() > > > https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/4cade1eae57abd93e0d6491eebce5f5f163ef186#a630d04e2df57150e6a092fc23f955c6ea0ce412 > > https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/369cb651abad11a3844fa38ea86ece40f4f40078 As a workaround I've used now: copy_libgcc /lib/x86_64-linux-gnu with the libpath hardcoded... but I have no idea how I should get that path properly. As far as I can see from your commit, you simply used the path that libargon2 was using? But I don't have that since argon2 doesn't link against it ;-) Any idea what would be the best solution in my case? > for Bookworm, but removed it with 2:2.7.2-1 since src:cryptsetup no > longer uses libargon. There is no stability guaranty for transitive > dependencies so I'd indeed argue the regression is not > src:cryptsetup's > fault :-) Adapting the above workarounds to your custom hookfile > should > solve the issue, though. Hmm yes, but I'm not sure if that would be a more proper solution than mine (with the hardcoded path), cause: In principle, my argon2 binary tool, might be from another arch as the installed libargon2 (if it's installed at all, which isn't necessarily the case). So not sure, but maybe: $ ldd /usr/bin/argon2 linux-vdso.so.1 (0x00007ffcc67d4000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1a1ee48000) /lib64/ld-linux-x86-64.so.2 (0x00007f1a1f058000) I should use libc for determination? > > > Did anyone of your report this issue anywhere else? > > Some years ago I asked the initramfs-tools maintainers to > inconditionally copy > libgcc_s to the initramfs image, but IIRC Ben argued it was too > seldom used to > justify the cost in size and impemented the libpthread detection > logic + > copy_libgcc() instead. > > I don't know if the detection logic can be improved/fixed in > initramfs-tools, > but despite what I promised elbrus in > https://bugs.debian.org/1032235#87 it > looks like I didn't file a bug. So... I assume the change in glibc is proper then... and a fix (if at all) would rather need to go to initramfs-tools? Would you recommend me to reassign #1069912 to initramfs-tools, asking for a more user-friendly solution? Thanks, Chris.
