Hi, On 2021-08-18 11:02, Matthias Klose wrote: > 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.
What do you mean with the wrong path? gcc-N-cross-ports failed to build because it was pointing to the wrong ld-linux.so.2. If it builds, I believe it points to the correct one. > Do you intend to fix that, or should that be worked > around in the c-t-b package? This is not something to fix in the glibc package. The packages generated by cross-compiling glibc have the correct paths, the issue is introduced by the path mangling done by the embedded dpkg-cross copy. The issue should be fixed there, not by patching glibc with hacks that have impacts on the non mangled packages. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
