Staticlib built with musl linking problems in Ruby gem

[tombruijn]

Hi!

I tried to build a staticlib to the x86_64-unknown-linux-musl target, with the std included and libc dependency.

It compiles without errors.

However, when adding it as a dependency to a Ruby gem on alpine linux it throws an error:

$ ruby extconf.rb
checking for rust_example_init() in -lrust_example... yes
creating Makefile
$ make clean
$ make
compiling rust_example.c
linking shared-object rust_example/rust_example.so
/usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./librust_example.a(__stdout_write.lo): relocation R_X86_64_PC32 against protected symbol `__stdio_write' can not be used when making a shared object
/usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:254: recipe for target 'rust_example.so' failed
make: *** [rust_example.so] Error 1

Meta

$ rustc --version --verbose
rustc 1.13.0-nightly (4f9812a59 2016-09-21)
binary: rustc
commit-hash: 4f9812a59ab7247f0f52b01ca89b0793a2d289c3
commit-date: 2016-09-21
host: x86_64-unknown-linux-gnu
release: 1.13.0-nightly

Example project

I'm using a docker container to build the staticlib. An example project with the full process automated and documented can be found here: https://github.com/tombruijn/rust_example
It builds the staticlib on a ubuntu 16 machine with musl-tools installed and set to use musl during compilation.

Things of note:

• The Ruby gem install works on a debian machine (see the debian branch in the example repo)
• When I build an executable with musl, std and libc it runs as expected.

Anyone knows what is going wrong here?

[alexcrichton]

Thanks for the report! Unfortunately this may not be a case that works today. Right now the Rust compiler expects the musl target to be linked statically, so the staticlib you've produced actually has all of libc.a (musl's version) included in it. This means that when it's linked into a shared object that conflicts with musl's dynamic library version of libc (libc.so) and wreaks all kind of havoc (including the weird error you're seeing).

Note, though, that there's an RFC (rust-lang/rfcs#1721) about customizing this, so if that lands it'd just be RUSTFLAGS=-Ctarget-feature=-crt-static cargo build and then everything would work just fine! (in theory)

[tombruijn]

@alexcrichton thanks for the response! Too bad it doesn't work yet, at least I now know why :) I'll be happy to run some tests once there's a alpha/beta release with support.

I'm subscribed to the rfcs issue and have my own issue for this problem in a private repo. You can close this issue if needed.

[wagenet]

This is what we're doing for Skylight: https://users.rust-lang.org/t/linking-problems-in-ruby-gem-using-a-rust-staticlib/7467/2?u=wagenet. It works fine for non-musl and in my basic testing appears to work for musl, but some testers have reported issues. I'm still investigating.

[alexcrichton]

@wagenet oh right, thanks for the info! Your use case though is opening a musl dylib in a glibc process, right? (or am I misremembering). If that's the case, then this is slightly different in the sense that it's a musl dylib in a musl process, but the point still stands!

[Mark-Simulacrum]

@tombruijn states here that this is fixed, closing.