On 8/6/21 10:44 AM, Aurelien Jarno wrote: > 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.
this fixes the gcc-N-cross-ports build, but leaves the libc.so with the wrong path of ld-linux.so.2. Do you intend to fix that, or should that be worked around in the c-t-b package? Matthias
