Hi, On 2024-11-24 12:48, Helmut Grohne wrote: > Source: glibc > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > Hi Aurelien, > > since a while I am observing that some multilib-enabled cross builds > fail in dpkg-shlibdeps. Examples: > > https://jenkins.debian.net/job/rebootstrap_mips64el_gcc14/6/console > https://jenkins.debian.net/job/rebootstrap_mips64_gcc14/10/console > https://jenkins.debian.net/job/rebootstrap_i386_gcc14_diffoscope/4/console > https://jenkins.debian.net/job/rebootstrap_i386_gcc14_supported_diffoscope/4/console > https://jenkins.debian.net/job/rebootstrap_mips64r6el_gcc14_supported/7/console > > The common pattern is failure to locate libc.so.6 in the multilib call > for dpkg-shlibdeps.
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/*. 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. > I think we need to explicitly pass the correct > library directory here. As a result, I came up with the attached > one-line change to the dh_makeshlibs invocation. It looks up the slibdir > for the current pass and appends it via the -l flag. What do you think > about the proposed change? Does it have any downsides? It appears to > practically solve instances of the mentioned problem. Please let me know > if you would like further details to assess the proposed change. 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. 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)) Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
