On 15/11/14 05:24 PM, Paul Colomiets wrote: > Hi Brian, > > On Sat, Nov 15, 2014 at 11:23 PM, Brian Anderson <[email protected]> > wrote: >> I believe it is not possible to link to glibc statically. My understanding >> is that to get a Rust binary that does not depend on a system-provided libc >> at all we need to add explicit support for alternate libc >> implementations[1]. >> > > Thanks. This really explains why problem is so hard. It seems that > it's possible to link to glibc, with the issue of non-working name > resolution (which is pluggable in glibc) and dlopen (for obvious > reasons). That would work for me for now. > > Still, when you are talking about "system-provided libc", do you mean > that if I would compile Rust on e.g. Alpine linux (which has musl libc > by default), I will be able to link rust program with musl libc > statically?
The limited static linking support in glibc is misleading, because it's
quite broken.
Here's a simple example of a performance bug (time it with and without
using -static):
#include <time.h>
int main(void) {
struct timespec ts;
for (unsigned i = 0; i < 1000000; i++) {
clock_gettime(CLOCK_MONOTONIC, &ts);
}
}
Unlike musl, glibc has no vdso support without dynamic linking.
Statically linking all libraries is also different than a *fully* static
binary which is incompatible with features like ASLR. Rust enables PIE
(full ASLR) by default so `-static` alone is poorly defined and will
likely break at compile-time or runtime.
Rust's current approach to FFI is to hard-wire the entire ABI of a
specific version / configuration of the library. It's unlikely that it
will work with musl at this time, despite musl's progress towards
support for the glibc ABI.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
