Question: whose responsibility is it to provide builtins used by C code?

[parched]

If you link some C code into your rust executable (e.g., libc) and that code uses some builtins that aren't needed by Rust (e.g., long double builtins), whose responsibility is it to provide them? This crate or something else?

In other words, should this crate provide C builtins or, if the target is linker_flavour is gcc or ld, should libgcc be added to the list of things linked?

CC @alexcrichton @japaric

Related #201

[alexcrichton]

I'd personally expect these to come from libgcc, not compiler-builtins. This crate is in general targeted only at Rust's needs, not C's.

[Amanieu]

In the case of #201, the musl libc is shipped as part of the compiler. In that case it should be the responsibility of the compiler to provide the necessary symbols for linking the provided libc. I agree with alex though, this should be done by linking in libgcc or libcompiler-rt.

[parched]

Ok, so rustc should add libgcc to the linker commandline for all targets that use gcc or ld linker flavor?

What happens when someone wants to use compiler-rt instead, do we add a flag to rustc allowing the user to specify the c-builtins library, if and when that is needed?

[alexcrichton]

I don't personally think that rustc should do this, but rather a user should explicitly request libgcc.

[parched]

@alexcrichton Do you mean via #[link(name = gcc)] or RUSTFLAGS? It's really just a coincidence that every (std) rust executable doesn't need libgcc because all the libcs support long double.

[alexcrichton]

Yeah that's what I'd personally expect.

[Amanieu]

An alternative could be to add the libgcc dependency to the libc crate.

[Amanieu]

I think this is resolved by rust-lang/libc#1034.

We will link to libgcc when we provide a statically linked libc as part of the libc crate (musl), but otherwise leave it to the dynamic linker to find libgcc.so if it is required by libc.so.

[alexcrichton]

👍