Hi Aurelien, On Sat, Jan 04, 2025 at 03:42:20PM +0100, Aurelien Jarno wrote: > ABI tags are used on the glibc side mostly to define the minimum kernel > version, I think it's just a nice side effect that they allows the > library not to be picked-up in that case. The ld.so.cache has never been > designed with multiarch in mind, so in theory it should not contain > things from a foreign architecture. The way to go is to rewrite > ldconfig/ld.so.cache/ld.so to also look at the machine, bitness, > endianess and OS/ABI. But this is a significant work that probably need > to be done upstream to avoid diverging even more.
I concur with all of this. Especially the part about doing it upstream. However, I note multiarch still seems like something that is not received well by upstreams to this date. I recently interacted with gcc people about an issue that was strongly influenced by multiarch and got a halfway angry reply about not having upstreamed the multiarch work. I'm not sure how to proceed here. At least on the gcc side, I've not had much success about even getting my patches reviewed let alone accepted and I don't expect it to be any better on the glibc side. I'm willing to work on this, but I'd need a mentor from the respective organization who can make the acceptance process work in a practical way. > > > Yes, I agree we can do that. I don't fully like the way the slibdir is > > > accessed, it assumes that the package name contains the name of the > > > build pass, it is the case currently, but might be different if we add > > > back some optimized packages. That's because we don't track packages > > > generated by a build pass, it's something we have to fix at some point > > > to be able to switch to the dh_sequencer. > > > > Indeed. Do you anticipate doing optimized multilib packages? > > We used to have some, they have been removed in favor of ifunc, but I am > expecting that unless we raise the baseline of the amd64 architecture, > people will come back strongly with optimized flavour for amd64. They > will likely contain a - like in x86-64-v3. Alternatively we might ship > it in the same package (that will solve many other issues like lockstep > upgrading of optimized and non-optimized flavour), but that will make > the container people unhappy... You leave me slightly confused here. I see that way may need an optimized variant of libc6:amd64. What I'm not quite seeing yet is whether we also need an optimized variant of libc6-amd64:i386 where the -l flag would be relevant. As long as we do not have optimized multilib packages, we may get away with not solving the corner case. > Yes, it will definitively include /usr/libsomething, but in addition of > the already built-in /usr/lib32 and /usr/lib64 paths. In short that will > only add /usr/libo32 and /usr/libx32 for the mips and x32 packages. > That might be an issue (in that case already existing due to the > built-in paths), but IMHO let's just make all multilib packages behave > the same way, to avoid bugs specific to some architectures. Is that really the case? I remove most of /etc/ld.so.conf.d. In any case, it probably is good enough. Let me thank you for accepting the extra complexity that I impose on glibc for the bootstrapping use case and hope that it gets us far enough. I also have an issue with bootstrapping i386 (or x32) from amd64 where building libc6-amd64:i386 fails as it picks up the wrong stuff and ends up conflicting with the build architecture. Please do not understand this as a bug report. I have not prioritized this on my side and do not expect you to look into it. Helmut
