XPost: linux.debian.maint.glibc

Hi,

On 2024-11-24 12:48, Helmut Grohne wrote:

Source: glibc
Tags: patch
User: helmutg@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 aurelien@aurel32.net http://aurel32.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.glibc

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)