Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Staticlib built with musl linking problems in Ruby gem #37007

Closed
tombruijn opened this issue Oct 6, 2016 · 5 comments
Closed

Staticlib built with musl linking problems in Ruby gem #37007

tombruijn opened this issue Oct 6, 2016 · 5 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries

Comments

@tombruijn
Copy link

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
Copy link
Member

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
Copy link
Author

@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
Copy link
Contributor

wagenet commented Oct 7, 2016

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
Copy link
Member

@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!

@steveklabnik steveklabnik added the A-linkage Area: linking into static, shared libraries and binaries label Oct 7, 2016
@Mark-Simulacrum
Copy link
Member

@tombruijn states here that this is fixed, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries
Projects
None yet
Development

No branches or pull requests

5 participants