Current stable sys-fs/cryptsetup-2.3.2 fails to build with use flag 'static' enabled due to multiple definitions of close_all_fds and mkdir_p: (.text.close_all_fds+0x0): multiple definition of `close_all_fds'; /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib64/libblkid.a(libcommon_la-fileutils.o):(.text+0x180): first defined here (.text.mkdir_p+0x0): multiple definition of `mkdir_p'; /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib64/libblkid.a(libcommon_la-fileutils.o):(.text+0x320): first defined here Reproducible: Always
Note that the stable part isn't too relevant because gcc 10 is not yet stable.
Created attachment 679904 [details] build.log
Created attachment 679907 [details] emerge --info
(In reply to Sam James from comment #1) > Note that the stable part isn't too relevant because gcc 10 is not yet > stable. I have stable gcc-9.3.0-r2 here.
(In reply to Stefan Huber from comment #4) > (In reply to Sam James from comment #1) > > Note that the stable part isn't too relevant because gcc 10 is not yet > > stable. > > I have stable gcc-9.3.0-r2 here. Whoops, sorry!
Created attachment 683821 [details] Set of patches for eapply_user as a workaround This is due to both util-linux and systemd both defining those functions without proper namespacing. There are no references to either mkdir_p() or close_all_fds() in cryptsetup even. In dynamic linking this is not an issue because there are no such symbols in cryptsetup to resolve and within each library the addresses of those symbols are already known. Those functions are not part of the APIs of those packages, none of the headers files they install contain references to them. I'm not sure how to resolve it other than having upstream rename the functions, which I believe is unlikely. Unless there is an equivalent linker option of: "for systemd code use mkdir_p installed by systemd and for util-linux use mkdir_p installed by util-linux". Even weak binding them wouldn't resolve the collision. As a workaround, I've attached this bug a set of patches that rename those colliding functions. Like I said, they are not part of the API and I don't see them causing any issues. Even then, please use at your own risk.
This makes it a tricky situation. The point is that people like me use cryptsetup with static use flag to create initramfs images for systems with encrypted filesystems. I guess this is actually the main reason for having a statically linked cryptsetup. What role is systemd playing in this use case? Is there a chance to build a systemd-stripped statically linked cryptsetup by some sort of "initramfs" use flag? Or is there some more elegant way?
Same issue here.
I would suggest reporting the issue to cryptsetup upstream. I don't think this is something we should hack around with in Gentoo at this point. The cryptsetup build system provides the --enable-static-cryptsetup configure option, which suggests a willingness to support static binaries and the problems that come with them. They may be willing to implement a workaround in crytpsetup or work with the util-linux and systemd developers to rename the symbols in either project.
Reported an issue upstream: https://gitlab.com/cryptsetup/cryptsetup/-/issues/623
A fix is on the way upstream in util-linux, c.f.: https://github.com/karelzak/util-linux/commit/867df2617cdf2a0eca0778c016ac684ead7c91c7 The issue report for cryptsetup contains further details. In particular, static linking might be dropped in the future.
Created attachment 684966 [details, diff] Ported patch from upstream for util-linux
The patch added is a port from the master branch of util-linux to be applied against current stable util-linux-2.35.2. As mentioned in the issue report of cryptsetup, this patch will be available to util-linux 2.37 and 2.36.2: https://gitlab.com/cryptsetup/cryptsetup/-/issues/623#note_495974073 Note that I cannot test cryptsetup yet as bug #762017 of lvm2 is blocking cryptsetup with static use flag.
Short udpate: If have emerged lvm2 with static-libs only, which is sufficient for cryptsetup[static], and with the patch of util-linux it works now.
(Oh yes, sorry!)
*** Bug 788358 has been marked as a duplicate of this bug. ***
I believe this issue has been fixed through some combination of util-linux, lvm2, and cryptsetup changes.
