Compilation error in Rust 1.6 stable

[navidR]

I didn't encounter this in 1.6 when it was beta. This happens only in 1.6 stable.

└──> Temporary $ >> cd rust/
┌─[21:01:11]─[navid@WORKSTATION]
└──> rust $ >> cargo new test --bin
┌─[21:01:16]─[navid@WORKSTATION]
└──> rust $ >> cd test/
┌─[21:01:17]─[navid@WORKSTATION]
└──> test $ >> ls
Cargo.toml  src
┌─[21:01:18]─[navid@WORKSTATION]
└──> test $ >> cargo build
   Compiling test v0.1.0 (file:///home/navid/Temporary/rust/test)
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/navid/Temporary/rust/test/target/debug/test.0.o" "-o" "/home/navid/Temporary/rust/test/target/debug/test" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/navid/Temporary/rust/test/target/debug" "-L" "/home/navid/Temporary/rust/test/target/debug/deps" "-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-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-ca9f0d77.rlib" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "compiler-rt"
note: /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ca9f0d77.rlib(std-ca9f0d77.0.o): In function `dynamic_lib::_$LT$impl$GT$::open::hda73d3129880e7b9P1d':
std.0.rs:(.text._ZN11dynamic_lib13_$LT$impl$GT$4open20hda73d3129880e7b9P1dE+0xcf): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/libpthread.a(libpthread.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/libpthread.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

error: aborting due to previous error
Could not compile `test`.

To learn more, run the command again with --verbose.
┌─[✗]─[21:04:52]─[navid@WORKSTATION]
└──> tmp $ >> rustc --version --verbose
rustc 1.6.0 (c30b771ad 2016-01-19)
binary: rustc
commit-hash: c30b771ad9d44ab84f8c88b80c25fcfde2433126
commit-date: 2016-01-19
host: x86_64-unknown-linux-gnu
release: 1.6.0
┌─[21:05:09]─[navid@WORKSTATION]
└──> tmp $ >> cat /etc/fedora-release 
Fedora release 23 (Twenty Three)
┌─[✗]─[21:06:02]─[navid@WORKSTATION]
└──> test $ >> sudo dnf list installed | grep -i glibc
glibc.i686                             2.22-7.fc23              @System         
glibc.x86_64                           2.22-7.fc23              @System         
glibc-benchtests.x86_64                2.22-7.fc23              @System         
glibc-common.x86_64                    2.22-7.fc23              @System         
glibc-devel.i686                       2.22-7.fc23              @System         
glibc-headers.i686                     2.22-7.fc23              @System         
glibc-static.i686                      2.22-7.fc23              @System         
glibc-static.x86_64                    2.22-7.fc23              @System         
glibc-utils.x86_64                     2.22-7.fc23              @System        

// lets try simple hello world

┌─[✗]─[21:12:39]─[navid@WORKSTATION]
└──> tmp $ >> cat main.rs 
fn main() {
    println!("Hello, world!");
}
┌─[21:12:40]─[navid@WORKSTATION]
└──> tmp $ >> RUST_BACKTRACE=1 rustc --verbose main.rs 
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "main.0.o" "-o" "main" "-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-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-ca9f0d77.rlib" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "compiler-rt"
note: /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ca9f0d77.rlib(std-ca9f0d77.0.o): In function `dynamic_lib::_$LT$impl$GT$::open::hda73d3129880e7b9P1d':
std.0.rs:(.text._ZN11dynamic_lib13_$LT$impl$GT$4open20hda73d3129880e7b9P1dE+0xcf): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/libpthread.a(libpthread.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/libpthread.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

error: aborting due to previous error

Update : 1.7 beta is same, didn't work. The only rust did work : 1.5 stable and 1.6 when it was beta channel.

[brson]

Looks like we didn't compile something with -fPIC?

[brson]

@alexcrichton says it's trying to link to the static pthreads when it should be linking to dynamic.

[navidR]

in case :
1.6 :

"cc" "-Wl,--as-needed" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "main.0.o" "-o" "main" "-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-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-ca9f0d77.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-ca9f0d77.rlib" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "compiler-rt"
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/libc.a(libc-start.o): relocation R_X86_64_32 against `_dl_starting_up' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/libc.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

[navidR]

I edited the bug report last sentence because that caused confusionin IRC channel.

Update: 1.7 beta is same, didn't work. The only rust did work: 1.5 stable and 1.6 when it was beta channel.

[brson]

If this reproduces on common fedora installs it might be worth a point release.

[alexcrichton]

I was unfortunately unable to reproduce this in a docker container, @navidR do you know how I might be able to reproduce this locally? For example do you know if there's a standard set of packages that I need to install to get this to reproduce?

[alexcrichton]

Note that I think that also means that an "out of the box" install may not fail, but I also don't really know what an out of the box install for fedora looks like

[navidR]

@alexcrichton I am working on it , it seems something broken (silently) about one package.I couldn't reproduce this bug in another fedora 23 too , but I am sure there is something funny going on between fedora and rust . I talked to #fedora guy's , I am working on it. The problem is my fedora installation in my desktop is almost as vanilla as possible, so I wouldn't say there is something wrong about my fedora (because (beta 1.6 || stable 1.5) works. I am investigating.

[navidR]

@alexcrichton @brson After talking to fedora guy's

sudo dnf install --allowerasing glibc-devel-2.22-7.fc23.x86_64 glibc-devel-2.22-7.fc23.i686

Solved the problem seems there is problem between two version of glibc (glibc-devel-2.22-3 vs glibc-devel-2.22.7).

[alexcrichton]

Interesting! Is this something that's likely to happen frequently in fedora? For example if I were to locally follow a standard setup would it then be possible that I would also need to run that command? Or was this isolated to just a possible bug locally?

[navidR]

@alexcrichton it happens frequently for me. I do not remember precisely but when I was trying to cross compile some package or doing some other stuff, I should provide --allowerase flag (to dnf to change glibc ) (I am talking particularly about glibc ), though I am not specialised in fedora , but I will investigae this problem further .
As far as I can tell this may cause problem to other users too (as it caused problem for me in the past).

[alexcrichton]

Ok, @navidR if you can get a way to repro from a bare system (e.g. a bare docker image) it'd be quite helpful for evaluating in terms of a fix as well as whether we may want a point release.

Otherwise @brson to me this seems that if it's nonstandard (which it appears to be so far kinda?) it may not necessarily warrant a point release, but perhaps a backport if we get a fix for it.

[navidR]

@alexcrichton After investigating this bug in #fedora IRC channel (two glibc-static package - i686 and x86_64 - version cannot be installed in the same time), it seems it is mostly fedora's related issue than Rust. So I would say this bug is done and safe to close in my opinion, though I am going to report it in fedora bug reporter.

[cyplo]

Had same issue, sudo dnf install --allowerasing glibc-devel-2.22-7.fc23.x86_64 glibc-devel-2.22-7.fc23.i686 solved it for me.

[alexcrichton]

@navidR ok thanks for the investigation! If this is a fedora bug then I'll close this in favor of that. Do you have a link to the bug report that we could drop here as well?

Also thanks for confirming the fix as well @cyplo!