Summary: | sys-devel/gcc-config: ld.so.conf.d misordered gcc paths | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Pouzzner <douzzer> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=297685 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Daniel Pouzzner
2023-02-07 20:05:25 UTC
The ld.so.conf.d ordering is intentional -- we discussed it recently in #gentoo-toolchain and I don't think it's plausible to change it. See bug 297685 too. It's tricky because yes, there's this frustrating interaction with libstdc++ where you can't downgrade the compiler anyway, but also, the risk of breakage of anything using e.g. libgcc isn't great either. I personally noticed this after having 13 installed on one system & finding libubsan was coming from 13 despite not having selected it. Please file a new bug for the emerge issue for us to discuss that, as they're separate. Thanks for the background. The nontriviality is approximately what I feared, and I think we're stuck with this status quo. Wide deployment of -rpath would clearly be worse as it would lead to a neverending hurricane of package rebuilds around compiler upgrades. So what we're counting on going forward is that the .so's bundled with the compiler are ABI-compatible with the .so's from older compilers. I think the gcc people know we're all depending on that. If the only practical fallout is that system daemons need to be restarted to get them onto the updated .so's, that's not a big deal. |