On Fri, 03 Dec 2021 at 18:29:33 +0100, Florian Weimer wrote: > > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote: > >> If someone wants to upstream the multi-arch patches, that would be > >> great. > > > > I think multiarch is mostly build-time configuration rather than patches. > > We would have to take the table out of dpkg-architecture and put it into > upstream glibc (or gcc or binutils), otherwise you can't build a > multi-arch glibc on a non-Debian system.
Sorry, you asked about patches, so I thought you were under the impression that Debian was patching glibc to have it use multiarch library directories. I believe it's mainly done with build-time configuration rather than by patching, so there isn't necessarily anything to upstream, because most of what's necessary to enable/allow that build-time configuration is already upstream - unless you want glibc to be generically aware of multiarch paths even when built on non-Debian? Is that your goal here? As I said, a 99% implementation of multiarch tuples is to take the GNU tuple that any Autotools-based build system already relies on, discard the vendor part, and normalize a finite number of special cases (i[3456]86 and arm* are the only ones I'm aware of). I believe the people who did the early design of multiarch were hoping to standardize it via something like LSB, but that effort seems approximately as dead as LSB itself. systemd has an independent implementation of the list of known multiarch tuples: https://github.com/systemd/systemd/blob/main/src/basic/architecture.h https://github.com/systemd/systemd/blob/main/src/basic/architecture.c Some sort of change to the expansion of $LIB is maybe the only thing needed in addition to build-time configuration, because the upstream implementation of $LIB makes the assumption that only the last path segment of the ${libdir} is desired in $LIB, which is usually the case but happens to be untrue for multiarch. > In addition to get the right value for $LIB, it's also desirable to get > the default search paths right. This is done by runtime configuration rather than patching, at the moment, for example this file installed as part of libc6:amd64: $ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf # Multiarch support /usr/local/lib/x86_64-linux-gnu /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu If you would prefer this to be hard-coded into ldconfig, I suspect there's no implementation right now that could be upstreamed. > And there's also /usr/libexec/getconf to worry about. At the moment, /usr/bin/getconf is only installed for the "main" architecture (more precisely, for whichever architecture of libc-bin is installed). If there's meant to be one getconf per architecture, then it wouldn't be able to appear in /usr/bin or /usr/libexec with that name. As with ld.so, this is not unique to multiarch: multilib would have the same problem. Is that /usr/libexec/getconf upstream, or is /usr/libexec/getconf something else? smcv