Dear GCC Maintainers, As you might or might not be aware, we are currently discussing which way to go to complete the usrmerge transition in Trixie. There are a few viable options on the table, and we are pondering on the pros and cons. Full discussion is on debian-devel [1]. The context here is canonicalizing every package, so that all packages ship files under /usr, and nothing ships files under the legacy /bin, /sbin, /lib* directories. There's one particular option that has surfaced, and we'd like to hear your opinion on it. There's a particular use case that some folks are interested in, that fundamentally involves maintainting bootstrapping tools with minimal changes. If glibc ships ld under /usr/lib/, given the default PT_INTERP points to /lib/, programs won't start unless the symlink has been put in place by some bootstrapping tool. Now this is easy enough to do, but it got me thinking. Why wouldn't we change the default PT_INTERP to point to the actual, canonical path that is the default in Debian? To me, it makes sense that Debian tools are built to implement the default settings for Debian. And given we have chosen to go with a filesystem layout where the actual, canonical path of ld is under /usr/lib, it makes sense to me that gcc in Debian should default to use that path as PT_INTERP. Of course we could satisfy this use case by manually patching the ELFs in the essential set by hand, that's certainly a viable fallback avenue to keep around and easy enough, if a bit of work. But the more I think about it, the more I am convinced that the default option working best for Debian is the one that matches the project's choice of a filesystem layout. After all, this is configurable in the toolchain for a reason. And the vast majority of the rest of the world has long since finished this transition, so I struggle to think where software built with this default wouldn't work. We are talking about Trixie here, so Bullseye as the last non-force-merged release will be oldoldstable at that point, and even that was default merged for new installations, and really old ones (oldoldoldoldstable at that point? I lost count) will be long EOL. I suppose they could still be around unmaintained, but who uses a toolchain from 8 years in the future to build software for an EOL distribution 8 years in the past? Normally it's the other way around, you use an older toolchain to build for newer targets, as even glibc adds new symbols and is not always forward compatible. Even the oldest Ubuntu release that one could possibly target from the newest Debian release, 18.04, is going to go EOL next month. Also on the question of compatibility for compiling software for other targets that are not Debian, this already requires passing the appropriate compiler and linker flags and environment variables. And the caller needs to ensure the environment, including linker flags, is appropriate for the target environment. Therefore, I don't think it would be unreasonable to require that if the target environment is split-usr, then the caller also needs to specify an appropriate '-Wl,-- dynamic-linker=/lib/ld-whatever' option, just as many other target- specific options need to be prepared. And it goes without saying that we will most likely still ship the top level symlinks for a very long time, they wouldn't go away immediately, so old software will still work as it does today. On the 'how' question there's obviously some options - patching GLIBC_DYNAMIC_LINKER* defines, adding optional build time prefixes to them, or a ship a default spec file - so it's not too important I think, the main question is another one. What would happen if we do this? There will be obviously some small set of packages that parse PT_INTERP and hard-code expectations and would need to be updated. But for the vast, vast majority of cases, does anybody see any obvious issues? There are precedents for this, I was told GUIX patches PT_INTERP distro-wide already to point to its store, so it does not seem that far fetched as an idea. Thoughts? [1] https://lists.debian.org/debian-devel/2023/04/msg00008.html -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part