Right now, we depend on glibc, and it cannot be statically linked. By default, Rust applications statically link everything but glibc already.
At least one core team member is strongly advocating for musl support for truly standalone binaries in the 1.1 timeframe, but nothing is likely to change for 1.0, and it's too early to decide on 1.1 features yet :)
Name resolution libraries are loaded dynamically [1,2], so glibc can't be linked statically if you want NSS to work. I gather there might be a way to explicitly link to a specific resolution library but this is practically unsupported/poorly documented.
It's generally considered a poor idea to statically link glibc, but if you don't rely on certain features, you can do it. For example, NSS won't work unless you add a bunch of flags for other libraries you specifically use, see https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...
Most people who focus on 100% statically linking just use a different libc. For example, Stali Linux, [1] has this to say: http://sta.li/faq
> it [is] nearly impossible to use glibc for static linking in non-trivial programs.
That said, if you want to give it a shot, it's technically possible, though we don't expose it for Rust yet, due to these kinds of landmines.
I'm looking forward to using rust in a constrained embedded environment where I control 100% of the software. I don't have to worry about such problems.
Awesome, then yes, you have several advantages here :) You'll be using nightly Rust for a while, as several features that target this use case are still unstable, like inline assembly. But it's a use case we do care a lot about.
That's funny, I always thought that GHC's lack of support for shared libraries and requiring static linking were serious obstacles to its adoption, but people are actually asking for this kind of thing now?
If you want to re-use any of the huge number of mature C libraries out there, you will need to link against glibc anyway.
Directly invoking system calls is quite the violation of the UNIX philosophy :)
May be I misunderstood something, but dropping dependency on glibc doesn't imply static linking.
Of course reusing C library means linking with libc and reusing C++ library means linking with libstdc++. But in a long perspective those libraries should be implemented with Rust to have all advantages of the better language.
And using rust without libc might help with some embedded use-cases, where people don't want to put unnecessary stuff. Rust as a 0-cost systems language theoretically could be used there instead of C.
Possibly glibc itself, but not a libc in general. While it's true that Rust can make system calls itself (though inline assembly isn't stable yet), we're not interested in re-implementing all of that.
Is there a documentation on how to build single binary executable for Rust?