Hi, On 2025-01-03 17:43, Helmut Grohne wrote: > Hi Aurelien, > > On Fri, Jan 03, 2025 at 11:51:23AM +0100, Aurelien Jarno wrote: > > dpkg-shlibdeps default to look in the standard (multiarch) paths, the > > "deprecated multilib paths" that is /lib32, /usr/lib32, /lib64, > > /usr/lib64, and in all paths declared in /etc/ld.so.conf and > > /etc/ld.so.conf.d/*. > > You're totally right about this! > > > It appears that your build is done with: > > > > | dpkg-checkbuilddeps: error: Unmet build dependencies: gperf libaudit-dev > > binutils-for-host (>= 2.38) g++-14-for-host g++-14-multilib > > > > g++-14-multilib is indirectly responsible for installing libc6-x32, > > which installs /etc/ld.so.conf.d/zz_x32-biarch-compat.conf, which adds > > /libx32 and /usr/libx32. > > > > In short this works for the standard multilib paths, but fails for the > > x32 and o32 ones. > > Thanks for pointing this out. I totally missed the fact that my builds > lack /etc/ld.so.conf.d. They actually lack those files on a deeper level > than you see. I have to forcefully disable them to be able to build at > all. The rebootstrap source does this: > > | # Since most libraries (e.g. libgcc_s) do not include ABI-tags, > | # glibc may be confused and try to use them. A typical symptom is: > | # apt-get: error while loading shared libraries: > /lib/x86_64-kfreebsd-gnu/libgcc_s.so.1: ELF file OS ABI invalid > | cat >/etc/dpkg/dpkg.cfg.d/ignore-foreign-linker-paths <<EOF > | path-exclude=/etc/ld.so.conf.d/$(dpkg-architecture "-a$HOST_ARCH" > -qDEB_HOST_MULTIARCH).conf > | EOF > > This is not unique to kfreebsd, but applies to other architecture > combinations as well. This generally applies to cross building in > principle, but to bootstrapping in particular. > > Do you see a better way of ensuring that we do not accidentally load > host libraries into build architecture tools?
Not really, this seems to me like a global issue that would need to be solved to make multiarch more useful. It has never been really integrated on the glibc side :( 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. > > 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... > > Anyway I don't have a lot better to propose, I ended up with the > > following, which removes the absolute path (relative is enough) and uses > > foreach to avoid the repetition: > > > > dh_shlibdeps -p$(curpass) $(foreach path,$($(lastword $(subst -, > > ,$(curpass)))_slibdir),-l/usr$(path)) > > I suppose this works. Would this not access the actual /usr/libsomething > as opposed to only considering the one in the package? I like the use of > foreach. 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. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
