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

Weird behavior when trying to build a fully static binary with MUSL (x86_64-unknown-linux-musl) #79624

Closed
axonasif opened this issue Dec 2, 2020 · 6 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. O-musl Target: The musl libc

Comments

@axonasif
Copy link

axonasif commented Dec 2, 2020

I'm new with rust, just started playing around with it.
Output of rustc --version --verbose:

rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: x86_64-unknown-linux-gnu
release: 1.48.0
LLVM version: 11.0

Basically I'm not getting an executable-format(it's still executable tho, more like a lib) output binary when I specify x86_64-unknown-linux-musl as the target. This is what I ran:

cargo build --release --target x86_64-unknown-linux-musl

After that on checking the output executable with file, I get the following:

ruston: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=be7ffcac4063277b96b8eeeba2adf0d3a02fcfe3, stripped

Also on running ldd:

        statically linked

While if I run cargo build --release --target i686-unknown-linux-musl, I kinda get my expected results.
file output:

ruston: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, BuildID[sha1]=5160d9b8fb9616aba4ecb05ce9e9d56638fdf187, stripped

ldd output:

        not a dynamic executable

I'm sorry if I've misunderstood anything and thanks in advance :)

Tl;dr: x86_64-unknown-linux-musl build target is generating ELF LSB shared object (dynamically linked) while i686-unknown-linux-musl is making ELF LSB executable (statically linked) binary.

@axonasif axonasif added the C-bug Category: This is a bug. label Dec 2, 2020
@jonas-schievink jonas-schievink added A-linkage Area: linking into static, shared libraries and binaries O-musl Target: The musl libc labels Dec 2, 2020
@petrochenkov
Copy link
Contributor

petrochenkov commented Dec 2, 2020

This happens because static_position_independent_executables is enabled in https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_linux_musl.rs but not in https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/i686_unknown_linux_musl.rs.
(static_position_independent_executables was enabled in #70740, not sure why it was done for x86_64 only.)

Static PIE is reported as "dynamically linked" by file.

@axonasif
Copy link
Author

axonasif commented Dec 2, 2020

This happens because static_position_independent_executables is enabled in https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_linux_musl.rs but not in https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/i686_unknown_linux_musl.rs.
(static_position_independent_executables was enabled in #70740, not sure why it was done for x86_64 only.)

Static PIE is reported as "dynamically linked" by file.

So, is there anything I could do regarding this issue ?
Maybe compiling the rust-compiler with static_position_independent_executables disabled in the .rs file as you specified would help ? Although, it seems like a complicated process 😅
Thanks!

@petrochenkov
Copy link
Contributor

I don't think anything needs to be done here?
(Besides enabling static_position_independent_executables for i686-unknown-linux-musl perhaps.)

This

Basically I'm not getting an executable-format(it's still executable tho, more like a lib) output binary

is the expected behavior, static position-independent executables are indeed executables, but they may confuse tools like file which may report them as dynamic libraries.

@axonasif
Copy link
Author

axonasif commented Dec 3, 2020

I don't think anything needs to be done here?
(Besides enabling static_position_independent_executables for i686-unknown-linux-musl perhaps.)

This

Basically I'm not getting an executable-format(it's still executable tho, more like a lib) output binary

is the expected behavior, static position-independent executables are indeed executables, but they may confuse tools like file which may report them as dynamic libraries.

Okay so, that means I got nothing to worry about, right ?

@petrochenkov
Copy link
Contributor

Right, closing as not-an-issue.

@plusls
Copy link

plusls commented Jan 13, 2023

This happens because static_position_independent_executables is enabled in https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_linux_musl.rs but not in https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/i686_unknown_linux_musl.rs. (static_position_independent_executables was enabled in #70740, not sure why it was done for x86_64 only.)

Static PIE is reported as "dynamically linked" by file.

I am wonder that why it only enable static_position_independent_executables for x86_64 but no enable in i686, although i686 don't support pic instruction, but can implement it by call and get return addr(in fact, gcc use it to implement pic in i686), so I think we can think i686 support pic, so we should enable static_position_independent_executables for it ?

I just want to build a i686 musl pie executeable file, but i found it link the crtbegin but not crtbeginS, and I finally found that static_position_independent_executables is false in i686 target.

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 C-bug Category: This is a bug. O-musl Target: The musl libc
Projects
None yet
Development

No branches or pull requests

4 participants