control: reassign -1 cross-toolchain-base-ports-46 control: tag -1 + patch control: tag -1 - moreinfo control: tag -1 - unreproducible
On 2021-08-05 18:59, Aurelien Jarno wrote: > control: tag -1 + moreinfo > control: tag -1 + unreproducible > > On 2021-08-04 19:03, Matthias Klose wrote: > > Package: src:glibc > > Version: 2.31-13 > > Severity: serious > > Tags: sid bullseye > > > > when cross-building glibc in the c-t-b packages, the libc.so linker file for > > some non-default multilib builds like the sparc build for sparc64 is broken, > > leading to build failures for at least all gcc-N cross multilib packages at > > least. > > > > $ cat usr/lib32/libc.so > > /* GNU ld script > > Use the shared library, but some functions are only in > > the static library, so try that secondarily. */ > > OUTPUT_FORMAT(elf32-sparc) > > GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a AS_NEEDED ( > > /lib/ld-linux.so.2 ) ) > > Can you point me where you got that file? It doesn't make sense from the > path and the content point of view. Also it's not what I get in the > libc6-sparc-sparc64-cross package generated by building > cross-toolchain-base-ports in a bullseye chroot. I get instead: > > | cat /usr/sparc64-linux-gnu/lib32/libc.so > | /* GNU ld script > | Use the shared library, but some functions are only in > | the static library, so try that secondarily. */ > | OUTPUT_FORMAT(elf32-sparc) > | GROUP ( /usr/sparc64-linux-gnu/lib32/libc.so.6 > /usr/sparc64-linux-gnu/lib32/libc_nonshared.a AS_NEEDED ( > /usr/sparc64-linux-gnu/lib/ld-linux.so.2 ) ) > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985617#62 says that the > > maintainer is investigating, but apparently this never happened. > > I *did* investigate, and checked that the changes in the linker files > are correct. I have just done that again for both cross-toolchain-base > and cross-toolchain-base-ports. Here are the differences I observed on > the linker scripts: I have ran a build of gcc-10-cross and gcc-10-cross-ports over the night. gcc-10-cross just built fine, but gcc-10-cross-ports indeed failed to build the sparc64 cross compiler as you reported. It appears that the embedded copy of dpkg-cross decided to map the multiarch path to /usr/$triplet/lib, leaving lib32, lib64 or libx32 to the other multilib builds. This causes an issue for the dynamic linker symlink, which usually follows the upstream way of putting a 64-bit library in /lib64. At the end, it means the 32-bit dynamic linker ends-up in the /usr/triplet/lib directory containing the 64 bit libraries. This is not a big deal for most architectures, except when the 32- and 64-bit dynamic linkers have the same name like on sparc64. The problem seems to have been identified, as one of the two is just removed in the debian/rules file, with this associated comment: # FIXME: don't remove these here, but find out why these are left in the glibc build The problem is that the removed one is the most useful one, breaking the assumption that /usr/$triplet/$rtld.so exists. The following patches fixes the issue for sparc64: diff -Nru cross-toolchain-base-ports-45/debian/rules cross-toolchain-base-ports-46/debian/rules --- cross-toolchain-base-ports-45/debian/rules 2021-03-03 15:22:03.000000000 +0100 +++ cross-toolchain-base-ports-46/debian/rules 2021-08-06 10:31:22.000000000 +0200 @@ -831,7 +831,7 @@ case "$$pkgname" in \ libc6-mips32-mips64-cross|libc6-mips32-mips64el-cross) \ rm -f $$tmp/usr/*/lib/ld.so.1;; \ - libc6-sparc-sparc64-cross) \ + libc6-sparc64-cross) \ rm -f $$tmp/usr/*/lib/ld-linux.so.2;; \ esac; \ if [ 'lib$(libgcc_base)1-dbg-$${cross_arch}-cross' = $$pkgname ]; then \ I guess the same fix is needed for gcc-10-cross-mipsen, but I haven't been able to build it yet. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net