[systemd-devel] Linking /lib64 to /usr/lib

Lennart Poettering lennart at poettering.net
Mon Feb 27 10:28:19 UTC 2023


On Sa, 25.02.23 10:01, Neal Gompa (ngompa13 at gmail.com) wrote:

> On Sat, Feb 25, 2023 at 9:45 AM Lennart Poettering
> <lennart at poettering.net> wrote:
> >
> > On Di, 21.02.23 16:00, Adrian Vovk (adrianvovk at gmail.com) wrote:
> >
> > > Hello all,
> > >
> > > Would you accept a patch to shared/base-filesystem that makes /usr/lib
> > > a fallback link target for /lib64? On my distro I don't support
> > > multilib at all and so everything ends up in /usr/lib.
> > >
> > > So for example, for x86_64 I'd change the target from
> > > "usr/lib/"LIB_ARCH_TUPLE"\0" "usr/lib64\0" to
> > > "usr/lib/"LIB_ARCH_TUPLE"\0" "usr/lib64\0" "usr/lib\0", and ditto for
> > > all the other architectures. That way no matter what, /lib64 always
> > > exists when necessary.
> >
> > I guess that makes some sense on a pure /lib/ file system. Send a
> > patch.
> >
> > (I mean, honestly, I personally wouldn't bother, and just usr /lib64/
> > as fedora does and no populate /lib/ with libraries. I mean, it's just
> > names, and the ABI is how the ABI is. But regardless, a patch using
> > /lib/ as final fallback we search for ld.so in sounds acceptable.)
> >
> > Submit via github.
>
> I don't think that's a good idea. Aside from violating the FHS, it
> creates an unexpected problem where multilib or multi-arch *is*
> available.

It does not. The logic looks for the ld.so executable, and only
creates the symlink then. If the executable is not in /lib/ under the
right name nothing happens.

Hence, the suggested change should chage anything for Fedora or opensuse.

> If Adrian wants to do that on his own distribution, that's
> fine. But as a generic patch in upstream systemd? No way. It would
> probably need to be reverted in Fedora and openSUSE (at the minimum)
> to prevent chaos.

nah, tha should be a non-issue.

That said, if I was Adrian I wouldn#t care either way, the ABI is how
the ABI is, i.e. the ELF binaries will hardcode the interpretor paths
with lib64 if the ABI says so, hence moving this around is just
creating headaches, not solving any.

But anyway, I'd be fine with the patch, it's minimal, has no effects
on systems who are not built like this, as it is the final fallback
only if the ld.so binary is not found elsewhere.

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list