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? > 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? > 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. Helmut
