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.0
+0100
+++ cross-toolchain-base-ports-46/debian/rules 2021-08-06 10:31:22.0
+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
