Re: [gentoo-dev] Re: last rites: sys-fs/eudev
Mike Gilbert writes: > On Thu, Sep 14, 2023 at 10:25 AM Arsen Arsenović wrote: >> Madhu writes: >> > systemd-udev cannot be built as a static binary again presumably a >> > carefully thought out design decision behind its design and >> > philosophy. >> >> Since static linking is seldom a good idea, it is more likely that >> simply nobody bothered. I don't recall any udev components in systemd >> v249 (which is the version I attempted to rebase eudev on top of) which >> can't be static linked. > > The main issue is symbol conflicts with several major projects. > > systemd makes careful use of ELF symbol visibility (hidden symbols) to > prevent conflicts when libudev or libsystemd are linked with other > projects. > > As I understand it, it is up to the linker to apply any visibility > rules. This doesn't work for static libs since the linker isn't > actually involved in their creation. A static library is really just > an archive with a bunch of unlinked ELF objects. > > Since the symbol visibility rules are not applied, attempting to link > against libudev.a or libsystemd.a leads to symbol conflicts in > packages like LVM2 and cryptsetup. There are some Gentoo bug reports > about this, but I can't find them immediately. > > The systemd project (upstream) has chosen not to work around these > conflicts by renaming symbols, and instead chooses not to support > static linking at all. They see static libs as being defective by > design. If the symbol visibility issue could be resolved at the > toolchain level, they would probably be more willing to support it. We can entertain the useless idea of static linking by trying partial linking. I can give that a shot later. Thanks for the background. Have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [gentoo-dev] Re: last rites: sys-fs/eudev
On Thu, Sep 14, 2023 at 10:25 AM Arsen Arsenović wrote: > Madhu writes: > > systemd-udev cannot be built as a static binary again presumably a > > carefully thought out design decision behind its design and > > philosophy. > > Since static linking is seldom a good idea, it is more likely that > simply nobody bothered. I don't recall any udev components in systemd > v249 (which is the version I attempted to rebase eudev on top of) which > can't be static linked. The main issue is symbol conflicts with several major projects. systemd makes careful use of ELF symbol visibility (hidden symbols) to prevent conflicts when libudev or libsystemd are linked with other projects. As I understand it, it is up to the linker to apply any visibility rules. This doesn't work for static libs since the linker isn't actually involved in their creation. A static library is really just an archive with a bunch of unlinked ELF objects. Since the symbol visibility rules are not applied, attempting to link against libudev.a or libsystemd.a leads to symbol conflicts in packages like LVM2 and cryptsetup. There are some Gentoo bug reports about this, but I can't find them immediately. The systemd project (upstream) has chosen not to work around these conflicts by renaming symbols, and instead chooses not to support static linking at all. They see static libs as being defective by design. If the symbol visibility issue could be resolved at the toolchain level, they would probably be more willing to support it.
Re: [gentoo-dev] Re: last rites: sys-fs/eudev
Madhu writes: [...snip...] > One of the planned consequences of this tree-cleaning is the removal > of genkernel, and the use of genkernel to build gentoo's initramfs. > > Genkernel uses eudev for udev, and it works because eudev can be built > statically. > > systemd-udev cannot be built as a static binary again presumably a > carefully thought out design decision behind its design and > philosophy. Since static linking is seldom a good idea, it is more likely that simply nobody bothered. I don't recall any udev components in systemd v249 (which is the version I attempted to rebase eudev on top of) which can't be static linked. NSS and friends are rather disconnected from udev-related components, and that's the closest thing I can think of to requiring shared objects (note, *not* the same as being unusable in a static-linked scenario). In addition, there's precisely zero reasons why an initrd must be composed of static linked components. > eudev works perfectly well for the job genkernel does, udev is not a > drop-in replacement for udev in genkernel initramfs because it doesn't > support static compilation. Removing eudev leads to a roadmap to > deprecate genkernel last-rite and remove it. > > I know you are a dracut user, but I've been unable to use dracut with > 1. cryptsetup swap + swsuspend + zfs on root. I've had an LUKS2 + LVM setup which also had a swap file for suspend with Dracut a few years back. You should be able to declare what files need to be brought up on the cmdline or in the config and have it do the rest. I've lost the notes on how exactly I did that since this was years ago, but I recall that all the information came from dracut.cmdline(7) (yeah, I know, manpages, unfortunate..), and I recall needing rd.luks.uuid=, resume=, and presumably root=zfs:... in your case. I had my suspend a volume in LVM, though, so my resume= pointed to /dev/foo/swap. Please give that a shot (but keep a copy of your current initrd so that you can retry easily). There are plenty of people on IRC who can help with your transition. Dracut is more flexible than it gets credit for. > Gentoo actively removes support for individual configurations, and > only supports is for configurations that fedora has already engineered > and controls because that is where the devs seem to be coming from. Developers tend to support tools they use, and developers tend to be more enthusiastic about tools that everyone uses and contributes to rather than a few specific ones, produced in-house ages ago, by people who are either no longer interested in those tools or in Gentoo. It has less to do with who made it and more to do with who uses it. Have a lovely day :) -- Arsen Arsenović signature.asc Description: PGP signature
Re: [gentoo-dev] Re: last rites: sys-fs/eudev
On Thu, 14 Sept 2023 at 01:20, Madhu wrote: > > * Rich Freeman > : > Wrote on Tue, 12 Sep 2023 05:18:51 -0400: > > On Mon, Sep 11, 2023 at 10:34 PM orbea wrote: > >> Regardless the disappointment is a valid concern when Gentoo is willing > >> to pull the rug up from under users feet under erroneous claims of the > >> project being dead. > > As a complete outsider, I think this conversation is focusing on the > > wrong issue. > > > > IMO the main reason it is getting treecleaned is the lack of a > > maintainer. Everything about this entire back-and-forth screams > > lack-of-maintainer. > > One of the planned consequences of this tree-cleaning is the removal > of genkernel, and the use of genkernel to build gentoo's initramfs. > > Genkernel uses eudev for udev, and it works because eudev can be built > statically. > > systemd-udev cannot be built as a static binary again presumably a > carefully thought out design decision behind its design and > philosophy. > > eudev works perfectly well for the job genkernel does, udev is not a > drop-in replacement for udev in genkernel initramfs because it doesn't > support static compilation. Removing eudev leads to a roadmap to > deprecate genkernel last-rite and remove it. genkernel doesn't use eudev from ::gentoo it uses its own private copy. > Gentoo actively removes support for individual configurations, and only > supports is for configurations that fedora has already engineered and > controls because that is where the devs seem to be coming from. What the actual hell are you on about
[gentoo-dev] Re: last rites: sys-fs/eudev
* Rich Freeman : Wrote on Tue, 12 Sep 2023 05:18:51 -0400: > On Mon, Sep 11, 2023 at 10:34 PM orbea wrote: >> Regardless the disappointment is a valid concern when Gentoo is willing >> to pull the rug up from under users feet under erroneous claims of the >> project being dead. > As a complete outsider, I think this conversation is focusing on the > wrong issue. > > IMO the main reason it is getting treecleaned is the lack of a > maintainer. Everything about this entire back-and-forth screams > lack-of-maintainer. One of the planned consequences of this tree-cleaning is the removal of genkernel, and the use of genkernel to build gentoo's initramfs. Genkernel uses eudev for udev, and it works because eudev can be built statically. systemd-udev cannot be built as a static binary again presumably a carefully thought out design decision behind its design and philosophy. eudev works perfectly well for the job genkernel does, udev is not a drop-in replacement for udev in genkernel initramfs because it doesn't support static compilation. Removing eudev leads to a roadmap to deprecate genkernel last-rite and remove it. I know you are a dracut user, but I've been unable to use dracut with 1. cryptsetup swap + swsuspend + zfs on root. Gentoo actively removes support for individual configurations, and only supports is for configurations that fedora has already engineered and controls because that is where the devs seem to be coming from.
