Skip to content

Compilation on Ubuntu 12.04 no longer succeeds #37786

Description

@alexcrichton

A simple hello world fails with:

$ rustc foo.rs
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "foo.0.o" "-o" "foo" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-1357b93f.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-1357b93f.rlib" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util"
  = note: /usr/bin/ld: /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-1357b93f.rlib(fileline.o)(.debug_frame+0x6c): reloc against `.debug_frame': error 2
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status


error: aborting due to previous error

Notably, this means that nightlies on Travis will fail to compile by default. Introduced at some point during cae6ab1...0ed9519, or maybe a recent change on the dist builder.

My money is currently on rust-lang-deprecated/rust-buildbot@a5d7cb7, but I have no idea why.

Activity

  1. alexcrichton commented on Nov 15, 2016

    @alexcrichton
    MemberAuthor

    Ok I'm now quite sure this was caused by rust-lang-deprecated/rust-buildbot@a5d7cb7.

    The current container is working with binutils 2.27, the old container used 2.25.1, and I've also tested out 2.26. The results I got below were from a cargo build of the standard library in the container with the respective binutils version, all in the rust-slave-dist container base (just differing in binutils versions). Taking this compiled standard library I then attempted to link each standard library with a ubuntu 12.04 container with the following results

    So overall this seems very similar to #34978 which happened because we updated from ubuntu 15.10 to 16.04, picking up a newer binutils version. That only affected the musl target, thankfully, though. The problem there was tracked down to a problem that was fixable, and we then since fixed it.

    Searching through the gas changelog we can see two changes in 2.27 and 2.6 that seem relevant:

    Changes in 2.27:
    
    * Default to --enable-compressed-debug-sections=gas for Linux/x86 targets.
    
    Changes in 2.26:
    
    * --compress-debug-sections is turned on for Linux/x86 by default.
    

    So with that in mind I passed --nocompress-debug-sections to the assembler via CFLAGS but I still got same error that the 2.26 build above got. Remembering #34978, though, I then also passed -mrelax-relocations=no and lo and behold it worked!

    So tl;dr; we need to pass -mrelax-relocations basically everywhere, and we also need to pass --nocompress-debug-sections as well when compiling C code.

  2. alexcrichton commented on Nov 15, 2016

    @alexcrichton
    MemberAuthor

    (sorry for the double post, deleted the first one which I clicked post too soon on)

  3. alexcrichton commented on Nov 15, 2016

    @alexcrichton
    MemberAuthor

    IRC snippets:

    15:10 <~acrichto> we have two options
    15:10 <~acrichto> 1) revert back to binutils 2.25
    15:10 <~acrichto> 2) pass two new fancy flags to disable the new behavior
    15:10 <~acrichto> so (1) is quite easy, just go build a new container and call it a 
                      day
    15:10 <~acrichto> will make rillian unhappy though
    15:10 <~acrichto> unfortunately I don't think we can do (2) though
    15:11 <~acrichto> passing two new fancy flags will break the rust build on a ton of 
                      platforms presumably which don't understand the flags
    15:11 <~acrichto> and the last thing I want to do is to do feature detection here
    15:11 <~acrichto> oh and I also don't know how to pass cflags just on the builders
    15:11 <~acrichto> so my curret thinking for a plan of action is:
    15:11 <~acrichto> a) revert back to binutils 2.25
    15:11 <~acrichto> b) switch nightlies to use rustbuild
    15:11 <~acrichto> c) update back to 2.27, but pass the fancy flags *only* on the 
                      builder
    15:12 <~acrichto> where (c) is possible b/c rustflags is much easier to configure w/ 
                      CFLAGS env vars and whatnot
    15:12 <~acrichto> or rather, I trust it a whole lot more
    

    Building the revert back to 2.25 now

    cc @rillian, this is going to revert the containers back to binutils 2.25, presumably breaking your i586 linux builds which you needed to fix your builds. We hope to upgrade back to 2.27 shortly, but just wanted to give you a heads up

  4. alexcrichton commented on Nov 15, 2016

    @alexcrichton
    MemberAuthor

    Ok, closing as the new image is now deployed. Hopefully tomorrow's nightly will have a fix for this, and if it doesn't we can reopen and rediagnose.

  5. rillian commented on Nov 16, 2016

    @rillian
    Contributor

    Thanks for the heads up. We should be on your builds starting with 1.14, and the i586-linux requirement is going away in a similar timeframe anyway. I'll keep an eye on it.

  6. jethrogb commented on Jan 21, 2019

    @jethrogb
    Contributor

    I can't find any evidence of compress-debug-sections being passed anywhere, was it determined that this is not needed after all?

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions