Hi, On 2021-08-18 15:43, Aurelien Jarno wrote: > 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.
For the record, the any/local-rtlddir-cross.diff patch has been introduced to avoid dealing with this kind of issue in armhf/powerpc-cross-toolchain-base, which later became cross-toolchain-base. It caused issues with the testsuite as reported in #985617 or reported upstream by Ubuntu there: https://sourceware.org/bugzilla/show_bug.cgi?id=25652 Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
