Hacker News Reader

Comment by didip | Hacker News Reader

Question for Rust peeps out there:

Is there a documentation on how to build single binary executable for Rust?

I'm assuming you're referring to static linking.

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 :)

  > Right now, we depend on glibc, and it cannot be statically linked.

Could you expand on this? Why can it not be statically linked?

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.

[1]: https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...

[2]: http://stackoverflow.com/questions/3430400/linux-static-link...

I understand this limitation. I can currently get around this by using --enable-static-nss.

Does rust currently expose any way to do this? Could I perform linking myself as a workaround?

> Could I perform linking myself as a workaround?

You can but it requires lots of black magic, and certainly a nightly rather than beta Rust ;)

http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-... is an old blog post that can get you started.

Wonderful -- thanks Steve! Best of luck on the upcoming release.

If you statically link libc, and then another library you use (potentially transitively) dlopen(3)s a library, you are going to have a bad time.

Of course, but that doesn't mean we shouldn't have the option, right?

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.

1: which got linked here a few times, most recently https://news.ycombinator.com/item?id=7261559

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.

Most of the people I've seen targeting this use case stub out their own stdlib, although that obviously gets cumbersome the more stuff you want to do.

Is there plans to drop glibc dependency? Rust should be able to do system calls itself and glibc should be as optional FFI library IMO.

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 :)

Does Rust have a UNIX dependency? If not, I don't see what the UNIX philosophy has to do with anything.

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.

Reply on news.ycombinator.com