#1076650 rust-sequoia-sop 0.35.0-3 FTBFS on mips64el ("relocation truncated to fit: R_MIPS_TLS_GD ...")

Package:
rustc
Source:
rustc
Description:
Rust systems programming language
Submitter:
Daniel Kahn Gillmor
Date:
2024-07-20 19:00:02 UTC
Severity:
normal
#1076650#5
Date:
2024-07-20 18:27:37 UTC
From:
To:
Hey mips64el builders--

https://buildd.debian.org/status/fetch.php?pkg=rust-sequoia-sop&arch=mips64el&ver=0.35.0-3&stamp=1721479018&raw=0
shows that rust-sequoia-sop 0.35.0-3 fails to build from source on mips64el.

It builds fine on all the other debian platforms.

I've copied what appear to the the relevant error messages, with a
little bit of context, at the end of this message.

0.35.0-1 build successfully on mips64el -- but there are two significant
differences between the versions:

 - 0.35.0-3 is building one additional binary, "sqopv", which was not
   being built by 0.35.0-1

 - 0.35.0-3 add "-C codegen-units=1" to RUSTFLAGS, in an attempt to
   reduce the size of the sqop and sqopv binaries.

Given that this error is happening in dh_auto_test, before sqopv is
getting built, i tend to think it's the RUSTFLAGS change.

I'm going to try removing the RUSTFLAGS change on mips64el to see
whether it can build successfully, but this suggests that there may be
some platform-specific bugs in rustc that put mips64el at risk.

I welcome any suggestions or pointers for other ways to resolve this!

Thanks for maintaining rustc in debian!

#1076650#12
Date:
2024-07-20 18:56:25 UTC
From:
To:
This looks like more a porting issue than a build daemon issue.
Forwarding the mail to the porter mailing lists.
----- Message transféré de Daniel Kahn Gillmor <dkg@fifthhorseman.net> ----- From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: submit@bugs.debian.org Reply-To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 1076650@bugs.debian.org X-Spam-Status: No, score=-17.0 required=4.0 tests=BAYES_00, BODY_INCLUDES_PACKAGE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, DKIM_VALID_EF,FOURLA,FVGT_m_MULTI_ODD,HAS_PACKAGE,PGPSIGNATURE, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6-bugs.debian.org_2005_01_02 Date: Sat, 20 Jul 2024 14:27:37 -0400 Subject: Bug#1076650: rust-sequoia-sop 0.35.0-3 FTBFS on mips64el ("relocation truncated to fit: R_MIPS_TLS_GD ...") Message-ID: <87h6cjgbqe.fsf@fifthhorseman.net> Package: rustc Version: 1.79.0+dfsg1-2 X-Debbugs-Cc: mips64el@buildd.debian.org, rust-sequoia-sop@packages.debian.org Control: affects -1 src:rust-sequoia-sop Hey mips64el builders-- https://buildd.debian.org/status/fetch.php?pkg=rust-sequoia-sop&arch=mips64el&ver=0.35.0-3&stamp=1721479018&raw=0 shows that rust-sequoia-sop 0.35.0-3 fails to build from source on mips64el. It builds fine on all the other debian platforms. I've copied what appear to the the relevant error messages, with a little bit of context, at the end of this message. 0.35.0-1 build successfully on mips64el -- but there are two significant differences between the versions: - 0.35.0-3 is building one additional binary, "sqopv", which was not being built by 0.35.0-1 - 0.35.0-3 add "-C codegen-units=1" to RUSTFLAGS, in an attempt to reduce the size of the sqop and sqopv binaries. Given that this error is happening in dh_auto_test, before sqopv is getting built, i tend to think it's the RUSTFLAGS change. I'm going to try removing the RUSTFLAGS change on mips64el to see whether it can build successfully, but this suggests that there may be some platform-specific bugs in rustc that put mips64el at risk. I welcome any suggestions or pointers for other ways to resolve this! Thanks for maintaining rustc in debian!
----- Fin du message transféré -----