Rustup should warn if libgcc is not installed on Alpine

Describe the problem you are trying to solve

In Linux distributions which depend on musl libc, cargo crashes if libgcc is not present.
This is the case in Alpine docker containers.

cargo
Error loading shared library libgcc_s.so.1: No such file or directory (needed by /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo)
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_GetIPInfo: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_GetDataRelBase: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_GetRegionStart: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_SetGR: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_FindEnclosingFunction: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_GetTextRelBase: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_Resume: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_DeleteException: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_RaiseException: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_GetIP: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_Backtrace: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_GetLanguageSpecificData: symbol not found
Error relocating /root/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/cargo: _Unwind_SetIP: symbol not found

Unless you know what to install in order to resolve this issue, it is baffling.
This problem will mainly affect beginners who want to learn rust.

Describe the solution you'd like

Rustup should warn on musl libc distributions (or maybe in any distribution) if it can't find libgcc.

Notes

Currently we have only Windows-specific information about toolchains and the like because it's semi-assumed that Linux and Mac OS people will know what they're doing to get their particular local distro's toolchains. It might be interesting for us to smoke-test components after installation and warn, but I'm not sure we can properly detect and diagnose this kind of issue across all our Linuxy targets.

Does rustc work? Is it only cargo which is failing like this? If rustc similarly fails, then we could could possibly add a message if we can't get rustc's version after install/update.

rustc does not work as well.
In fact, all the executables installed by rustup do not work without libgcc on Alpine.

What is the right way to install libgcc here? apk?

What is the right way to install libgcc here? apk?

Indeed.

Is this intended that cargo on musl target depend on libgcc dynamically and cannot be
replaced? I ping @pietroalbini as he may know the answer or who else know that.

Hmm, I don't really know who to ask.

Is this intended that cargo on musl target depend on libgcc dynamically and cannot be
replaced? I ping @pietroalbini as he may know the answer or who else know that.

That's a very good question. I haven't thought of that.

@ehuss

Thank pietroalbini. I ping @ehuss as another change to get answer for #2213 (comment) .

@mati865

I think the short answer is yes, libgcc_s.so is needed for now. I don't know if it is possible (or desirable) to avoid.

But you're also asking the wrong person, as I know next to nothing about musl. I think @mati865 is the expert here (rust-lang/rust#59302).

It's not specific to musl.
Similar error will appear when you try to run Cargo on glibc based distro without libgcc_s.so.1 installed.

The reason you can see it here but not on Ubuntu is because Alpine containers are stripped to the bare minimum and nothing has pulled libgcc as a dependency.

Generally you need linker (GCC or Clang) to use Rust and I'd be surprised if installing one of them haven't pulled libgcc.

So the only issue here could be missing documentation (I haven't checked).

So this is another example of "where does the documentation belong?" -- for Windows we include instructions on getting the MSVC tooling installed, but we don't include instructions really for other platforms. Where do we draw the line? Should the instructions be in the code or just the README, etc. There is at least some assumption that developers installing Rust with rustup know what they're doing with respect to developing software on their host platform because otherwise they're going to encounter many other interesting problems; but perhaps we (as an organisation) need to start documenting things more thoroughly so that newcomers are less surprised with the complexities?

I'm not sure that rustup can do anything programmatically to solve this, but perhaps more README docs are plausible.

So this is another example of "where does the documentation belong?" -- for Windows we include instructions on getting the MSVC tooling installed, but we don't include instructions really for other platforms. Where do we draw the line? Should the instructions be in the code or just the README, etc. There is at least some assumption that developers installing Rust with rustup know what they're doing with respect to developing software on their host platform because otherwise they're going to encounter many other interesting problems; but perhaps we (as an organisation) need to start documenting things more thoroughly so that newcomers are less surprised with the complexities?

I'm not sure that rustup can do anything programmatically to solve this, but perhaps more README docs are plausible.

Assuming that the user knows the platform they are using is a bad idea. What if they are a junior developer with no prior experience with Docker or with Alpine?

@thedrow

I feel it's a really tough call to make @thedrow -- is it our place to know all the possible targets and the possible dependencies our users might have or not have? Or is it our place to recommend that platforms document what's needed to get Rust working? If we assume it's the responsibility of the rust-lang org in some sense, then what's the right thing to do? Something specific to Alpine? Something where we guess that if you're unable to run rustc and the host and build are musl then you can run whatever this apk is? We don't instruct Ubuntu/Debian people to apt install binutils or for Fedora people to play with yum. Where is the cutoff and where does the documentation go, and who is responsible for ensuring it's correct and kept up to date?

I really want to do the right thing here, but we need to work out what that is.

I think we need to document about using Rustc on Alpine in Rustup's README file.
The requirement is that Rustc needs gcc or clang pre-existing.

@rustbot

@rustbot label: +O-linux

You might have better luck trying llvm-crt-replacement.

crt is a different thing, see the doc at https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/crt_objects.rs

But it's possible to bootstrap such toolchain that don't need libgcc_s.so or libunwind.so: rust-lang/rust#85600

> ldd stage1-tools-bin/cargo
	/lib/ld-musl-x86_64.so.1 (0x7f36d5bca000)
	libc.so => /lib/ld-musl-x86_64.so.1 (0x7f36d5bca000)
> lddtree stage2/bin/rustc
rustc => stage2/bin/rustc (interpreter => /lib/ld-musl-x86_64.so.1)
    librustc_driver-834e481193e490c9.so => stage2/bin/../lib/librustc_driver-834e481193e490c9.so
    libstd-e89f79e493e23cf7.so => stage2/bin/../lib/libstd-e89f79e493e23cf7.so
    libc.so => /usr/lib/libc.so

@rustbot

@rustbot label: +O-containers

What is the current recommended approach for this? Just apk add libgcc or any better toolchain?

@12101111

Couldn't this issue be solved by linking LLVM libunwind statically in the binary builds used for Rustup?

Even dynamic libunwind.so works as a drop-in replace replacing libgcc_s for me. I'm running Gentoo (with llvm+musl profile), I don't have GCC installed and all I had to do to fix the issue locally is:

ln -s /usr/lib/libunwind.so.1 /usr/lib/libgcc_s.so.1
ln -s /usr/lib/libunwind.so /usr/lib/libgcc_s.so

That's it. I'm pretty sure it would work on Alpine too. Rustup toolchains work and I didn't have to install GCC, my environment pretty much stays non-GNU. I'm using Rust daily for pretty much all of my programming work and I didn't notice any issues.

But I think that the right thing to do would be just linking libunwind statically. Any objections against that? I think that would make everyone happy:

People trying to use non-GNU musl-based distros/sysroots.
Users of GNU/glibc-based distros who are not going to notice any difference.

From what @12101111 says, it should be already possible. I can try building rustc myself and I will follow up with a config and options that need to be passed, if you are open for going with this solution.

It is unlikely that rustup's build will be significantly special-cased compared to the default build for that platform. If the appropriate thing to change here is to change the linkage of programs, then it is a problem that should probably be addressed upstream with rustc. I recommend that this issue be closed, because it incorrectly asks for rustup to have a special behavior regarding issuing warnings instead of simply solving the damn problem.

I totally agree, I created rust-lang/rust#119504 to discuss the problem there.

@djc

@djc I'm curious why this was closed? Although it would be great if rust didn't need libgcc_s on Alpine, it sounds like from rust-lang/rust#119504 it is not feasible to avoid it? Although I'm not clear on the resolution there.

It seems like it would be helpful for rustup to let you know that there is more you need to install (similar to how it helps you with installing msvc). I'd agree that trying to validate everything about the user's environment is correct is too much, but I think highlighting situations that are a frequent problem would be helpful.

@ehuss

@ehuss I mostly thought @workingjubilee made a compelling argument. If we think rustc doesn't have enough information to do a good job here, I'm open to considering adding a warning in rustup.

@ehuss

@ehuss After discussing with rustc folks (rust-lang/rust#119504), the conclusions are:

rustc cannot link to libgcc_s (or libunwind) statically, it would break linking with C++.
There is a project called llvm-libgcc which adds additional symbols on top of libunwind, which provides 100% compatibility with libgcc_s .

So yeah, probably the best thing to do would be warning that either libgcc_s or llvm-libgcc (a better choice if you completely want to avoid using GNU userland) need to be installed.

I think such a warning belongs properly with either cargo or rustc : this sort of platform specific caveat is a moving target, and not really connected to the 'manage downloads of binaries and proxy calls to them to let different projects use different versions

Navigation Menu

Repository navigation

Rustup should warn if libgcc is not installed on Alpine #2213

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Rustup should warn if libgcc is not installed on Alpine #2213

Description

Activity

kinnison commented on Jan 25, 2020

thedrow commented on Jan 26, 2020

rbtcollins commented on Jan 27, 2020

thedrow commented on Jan 27, 2020

tesuji commented on Jan 27, 2020

emilyalbini commented on Jan 28, 2020

thedrow commented on Jan 28, 2020

tesuji commented on Jan 28, 2020

ehuss commented on Jan 28, 2020

mati865 commented on Jan 28, 2020

kinnison commented on Jan 28, 2020

thedrow commented on Jan 28, 2020

kinnison commented on Jan 28, 2020

tesuji commented on Jan 30, 2020

10 remaining items

workingjubilee commented on Apr 29, 2021

12101111 commented on May 19, 2021

workingjubilee commented on May 21, 2021

rinarakaki commented on Aug 31, 2023

vadorovsky commented on Dec 31, 2023

workingjubilee commented on Jan 1, 2024

vadorovsky commented on Jan 1, 2024

ehuss commented on Jan 4, 2024

djc commented on Jan 9, 2024

vadorovsky commented on Jan 12, 2024

rbtcollins commented on Jan 13, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions