Repository navigation
error: relocation refers to local symbol "" [12], which is defined in a discarded section only when using ld.gold linker with --gc-sections #59652
Description
Activity
triage: P-high. Leaving nominated for now (What is going on here with
-Z emit-stack-sizes...?)Sorry for the breakage here. If PR #59401 is blocking anything feel free to revert it. It will probably be several days before I have some free time to dig into this (though my guess is that one of the extra, custom linker flags that firefox uses in their builds (see
MOZ_CARGO_WRAP_LDFLAGSin the linked bugzilla ticket) is not playing nicely with the new .stack_sizes section)14 remaining items
Well, gentoo allows you to tweak the system a lot and you do a lot of compilation with that system. I discovered gold is a bit faster in most cases, so I set it as the my system default linker. It's not the general default if you get a fresh gentoo system.
Okay, thank you @vorner, that is very helpful.
Just to share knowledge, I don't see the same problem with the
dipsticktest on my Linux host; here are my versions ofccandld:% cc --version cc (GCC) 8.2.1 20181105 (Red Hat 8.2.1-5) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % ld --version GNU ld version 2.31.1-13.fc29 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.I'll see if I can switch either of those around on this box in order to try to replicate the bug.
Update: Ooops, I should have reloaded the ticket before posting, there's been 16 hours of comments since @vorner posted.
Okay so my next question is what action to take at this point.
- First of all, the change to
-Z emit-stack-sizeswas part of the recent nightly-to-beta promotion. So this ticket is now a regression from stable-to-beta. I'm going to change the labels accordingly. - So an obvious change is to just remove the -Z emit-stack-sizes` emission (i.e. revert PR bootstrap: build crates under libtest with -Z emit-stack-sizes #59401, as suggested by @japaric above), unconditionally. I'm inclined to at least do that on the beta channel right now, to ensure that the regression is limited to nightly, not beta.
- The next question is whether to also remove that flag unconditionally on nightly too, or if we should somehow connect it to the choice of linker.
- Of course another option is to just say "this is a bug in
ld.gold; we are not going to try to work around it on our end." - (We could take an alternative route of trying to avoid injecting
--gc-sectionswhen it will break things. That would require, I think, inspecting whether the already-builtlibtest/libstdhas a stack_sizes section when we are building up our linker invocation. That, or assuming it has such a section whenever we are on the target that happens to match the strings as is done in PR bootstrap: build crates under libtest with -Z emit-stack-sizes #59401's bootstrap changes.)
- First of all, the change to
I've posted a PR to do the revert. Rather than solely cherry-pick it to beta, I have posted it against master (that is, rather than let the issue persist on the nightly builds, I want the behavior on nightly to match that of beta here).
I do welcome a more nuanced implementation, if someone wants to make one, for nightly. But I want to deploy the simplest way to address the regression on both master and beta right now. (And that's what PR #59911 is.)
Reacted by Michal 'vorner' Vaner and Apostolos- added a commit that references this issue
on Apr 18, 2019
tl;dr: #59652 (comment)
Cannot compile firefox anymore due to:
error: linking with ... cargo-linker
error: relocation refers to local symbol "" [12], which is defined in a discarded section
UPDATE bisect shows it's PR 59401
https://bugzilla.mozilla.org/show_bug.cgi?id=1541214
old info
This issue doesn't happen with Last **good** nightly:nightly-2019-03-28-x86_64-unknown-linux-gnu (default) rustc 1.35.0-nightly (33ef0ba 2019-03-27) binary: rustc commit-hash: 33ef0ba commit-date: 2019-03-27 host: x86_64-unknown-linux-gnu release: 1.35.0-nightly LLVM version: 8.0nightly-2019-03-29-x86_64-unknown-linux-gnu (default) rustc 1.35.0-nightly (237bf32 2019-03-28) binary: rustc commit-hash: 237bf32 commit-date: 2019-03-28 host: x86_64-unknown-linux-gnu release: 1.35.0-nightly LLVM version: 8.0The issue happens with
First bad nightly:
nightly-2019-03-29-x86_64-unknown-linux-gnu (default)rustc 1.35.0-nightly (237bf32 2019-03-28)
binary: rustc
commit-hash: 237bf32
commit-date: 2019-03-28
host: x86_64-unknown-linux-gnu
release: 1.35.0-nightly
LLVM version: 8.0
nightly-2019-03-30-x86_64-unknown-linux-gnu (default)
rustc 1.35.0-nightly (e782d79 2019-03-29)
binary: rustc
commit-hash: e782d79
commit-date: 2019-03-29
host: x86_64-unknown-linux-gnu
release: 1.35.0-nightly
LLVM version: 8.0
For each test I was using the same cargo:
cargo 1.35.0-dev (025b01ed 2019-04-01)
release: 1.35.0
commit-hash: 025b01edd0bba49b7e49c1cacc65bb1f6462ee57
commit-date: 2019-04-01
Errors look like this:
0:16.63 = note: /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-9b00dedc0dda6ebf.rlib(compiler_builtins-9b00dedc0dda6ebf.compiler_builtins.cqcjgied-cgu.0.rcgu.o)(.stack_sizes+0x0): error: relocation refers to local symbol "" [12], which is defined in a discarded section
0:16.84 section group signature: "(null)"
0:16.84 /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-e4188d26f42911c5.rlib(std-e4188d26f42911c5.std.b8iklw2d-cgu.0.rcgu.o)(.stack_sizes+0x1b): error: relocation refers to local symbol "" [696], which is defined in a discarded section
0:16.84 section group signature: "(null)"