cross-toolchain-base-devs team mailing list archive

[Matthias Klose <doko@xxxxxxxxxx>]

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