Skip to content

Latest nightly crashes on centos 5 #56849

Closed
#56892
Closed
Latest nightly crashes on centos 5#56849
#56892
Labels
T-infraRelevant to the infrastructure team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.

Description

@konstin
konstin
opened on Dec 15, 2018

This can be reproduced in a centos 5 docker container, such as the one provided by python's pypa:

docker run -it quay.io/pypa/manylinux1_x86_64 bash

curl https://sh.rustup.rs -sSf | sh -s -- -y --default-toolchain nightly
source $HOME/.cargo/env
rustup toolchain add stable
cargo new hello-world
cd hello-world
cargo +stable build # This works
cargo build # This crashes

The last command produces the following error:

error: process didn't exit successfully: `rustc -vV` (exit code: 1)
--- stdout
rustc 1.33.0-nightly (96d1334e5 2018-12-14)
binary: rustc
commit-hash: 96d1334e567237b1507cd277938e7ae2de75ff51
commit-date: 2018-12-14
host: x86_64-unknown-linux-gnu
release: 1.33.0-nightly

--- stderr
error: couldn't load codegen backend "/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so": "/lib64/libgcc_s.so.1: version `GCC_4.3.0\' not found (required by /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so)"

Versions:

cat /etc/redhat-release: CentOS release 5.11 (Final)
cargo -V: cargo 1.33.0-nightly (2cf1f5dda 2018-12-11)
rustc -V: rustc 1.33.0-nightly (96d1334e5 2018-12-14)
rustc -vV: crashes with the same output as above

Activity

  1. sfackler
    added
    T-infraRelevant to the infrastructure team, which will review and decide on the PR/issue.
    regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.
    on Dec 15, 2018

  2. alexcrichton commented on Dec 15, 2018

    @alexcrichton
    alexcrichton
    on Dec 15, 2018
    Member

    Some bisection reveals that this is a regression from #56051 actually, and I suspect the most likely candidate of that rollup is #55952

    cc @michaelwoerister

    As to why these symbols are just now showing up, I'm not sure...

  3. alexcrichton commented on Dec 16, 2018

    @alexcrichton
    alexcrichton
    on Dec 16, 2018
    Member

    Ok I've confirmed #55952 is the cause of this bug. I don't really know how this is showing up though as none of the symbols which use GCC_4.3.0 are even referenced from the file:

    $ readelf -s obj/build/x86_64-unknown-linux-gnu/llvm/bin/llc | grep GCC_4.3.0
   343: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatuntitf@GCC_4.3.0 (12)
   344: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __netf2@GCC_4.3.0 (12)
   346: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatunditf@GCC_4.3.0 (12)
   347: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __multf3@GCC_4.3.0 (12)
   350: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixtfdi@GCC_4.3.0 (12)
   351: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __eqtf2@GCC_4.3.0 (12)
   353: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __powitf2@GCC_4.3.0 (12)
   354: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatunsitf@GCC_4.3.0 (12)
   355: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatditf@GCC_4.3.0 (12)
   356: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixtfti@GCC_4.3.0 (12)
   357: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __lttf2@GCC_4.3.0 (12)
   358: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __extendsftf2@GCC_4.3.0 (12)
   361: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __letf2@GCC_4.3.0 (12)
   363: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __extenddftf2@GCC_4.3.0 (12)
   365: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixunstfti@GCC_4.3.0 (12)
   367: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixtfsi@GCC_4.3.0 (12)
   370: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __gttf2@GCC_4.3.0 (12)
   371: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __addtf3@GCC_4.3.0 (12)
   374: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __divtf3@GCC_4.3.0 (12)
   377: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __extendxftf2@GCC_4.3.0 (12)
   378: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __trunctfdf2@GCC_4.3.0 (12)
   382: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __trunctfxf2@GCC_4.3.0 (12)
   383: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixunstfdi@GCC_4.3.0 (12)
   385: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __unordtf2@GCC_4.3.0 (12)
   389: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __getf2@GCC_4.3.0 (12)
   390: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixunstfsi@GCC_4.3.0 (12)
   391: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floattitf@GCC_4.3.0 (12)
   394: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatsitf@GCC_4.3.0 (12)
   395: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __subtf3@GCC_4.3.0 (12)
   396: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __trunctfsf2@GCC_4.3.0 (12)

    None of those symbols are even used from llc or LLVM or... anywhere it seems. I have no idea what's putting that into some symbol table that needs to be resolved.

    This may be some LLD change though because if I disable ThinLTO for LLVM itself then these symbol references seem to go away...

  4. alexcrichton commented on Dec 16, 2018

    @alexcrichton
    alexcrichton
    on Dec 16, 2018
    Member

    Ok I've bisected this to rust-lang/lld@103b4dc, which makes sense sort of because that's injecting references to all builtins, even if we're not actually using them.

    I'll follow up with LLVM later tomorrow

  5. alexcrichton commented on Dec 16, 2018

    @alexcrichton
    alexcrichton
    on Dec 16, 2018
    Member

    Or actually, I've gone ahead and opened an upstream bug report to get the ball rolling there.

    This is also a beta regression as well, so I'm retagging as such.

    I believe the only solution we have for now on this is to turn off ThinLTO, so I'm going to send a PR to do that.

  6. alexcrichton
    added
    regression-from-stable-to-betaPerformance or correctness regression from stable to beta.
    and removed
    regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.
    on Dec 16, 2018
  7. alexcrichton
    added a commit that references this issue on Dec 16, 2018

    rustc: Disable ThinLTO for LLVM's build

    f905579

  8. alexcrichton commented on Dec 16, 2018

    @alexcrichton
    alexcrichton
    on Dec 16, 2018
    Member

    Er turns out this is likely already fixed at llvm-mirror/lld@3be4e82, so I can try out building that locally

  9. alexcrichton
    added 2 commits that reference this issue on Dec 16, 2018

    rustc: Update Clang used to build LLVM on LInux

    bbce189
  10. emilyalbini
    added a commit that references this issue on Dec 20, 2018

    Rollup merge of rust-lang#56892 - alexcrichton:new-llvm, r=michaelwoe…

    e801ffa
  11. Mark-Simulacrum
    added a commit that references this issue on Dec 21, 2018

    Rollup merge of rust-lang#56892 - alexcrichton:new-llvm, r=michaelwoe…

    b98afee
  12. emilyalbini
    added a commit that references this issue on Dec 21, 2018

    Rollup merge of rust-lang#56892 - alexcrichton:new-llvm, r=michaelwoe…

    2cd3b95
  13. Centril
    added a commit that references this issue on Dec 22, 2018

    Rollup merge of rust-lang#56892 - alexcrichton:new-llvm, r=michaelwoe…

    c2ed5cc
  14. bors
    closed this as completedin #56892on Dec 23, 2018

  15. konstin commented on Jan 8, 2019

    @konstin
    konstin
    on Jan 8, 2019
    ContributorAuthor

    This seems to have regressed again: https://travis-ci.org/PyO3/pyo3-pack/jobs/476983489 with this Dockerfile: https://github.com/PyO3/pyo3-pack/blob/master/Dockerfile

    Relevant excerpt:

    error: process didn't exit successfully: `rustc -vV` (exit code: 1)
--- stdout
rustc 1.33.0-nightly (8e2063d02 2019-01-07)
binary: rustc
commit-hash: 8e2063d02062ee9f088274690a97826333847e17
commit-date: 2019-01-07
host: x86_64-unknown-linux-gnu
release: 1.33.0-nightly
--- stderr
error: couldn't load codegen backend "/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so": "/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9\' not found (required by /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-8svn.so)"

  16. alexcrichton commented on Jan 8, 2019

    @alexcrichton
    alexcrichton
    on Jan 8, 2019
    Member

    Indeed! This should be fixed in #57429

  17. joar
    added a commit that references this issue on Jan 10, 2019

    Go back to nightly

    561448c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-infraRelevant to the infrastructure team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions