Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

I recall something about Rust's libc crate being glibc-specific. What's the status on that, and can one build the compiler on Solaris/illumos, NetBSD and OpenBSD?

View on HN

Here's an experience report by someone who managed to get Rust running on musl, for the purpose of creating fully static Rust binaries: https://gist.github.com/cl91/bb927df2525738502131#file-stati... (discussion at https://www.reddit.com/r/rust/comments/33boew/weekend_experi...).

UPDATE: Official (though still experimental) support for using musl with Rust code is landing in the compiler as we speak! https://github.com/rust-lang/rust/pull/24777

> What's the status on that

We still use glibc, yes. Being able to use musl instead is something that the community and team have been experimenting with lately.

> can one build the compiler on Solaris/illumos, NetBSD and OpenBSD?

The last two have community members that keep the build green. I _think_ illumos works, but I'm not sure.

Oh, look what just popped up: https://github.com/rust-lang/rust/pull/24777

Why does rust need a libc?

Im still new to rust, so forgive me if this is a stupid question.

No it's not a stupid question. libc (or CRT on windows) really is the library that exposes all the user space system libraries. It contains the functions to do IO, sockets, threads, and etc. So we use it to expose that functionality to rust users.

Now there are some languages, namely Go, that skip libc and just implement directly against the syscall interface. Go has the advantage of being able to draw from Google's vast experience interacting deep within the system, so it was comparatively cheap for them to do this.

For rust, it never really felt like it was worth the effort for the benefit we'd get out of it. It was more important to get the language done.

Programming languages on Windows other than C and C++ typically link with kernel32.dll and so on, and not a C runtime. This gives a stable interface at a slightly higher level of abstraction than syscalls. Relying on libc is more a Unixism; without duplicating a bunch of the work in libc, you simply can't use many system services in ways the end user expects - network name resolution comes to mind (NSS), but other things, like threads, don't have portable standards at a lower level.

There have been some efforts to make Rust utilize the native Windows API instead of libc on Windows. While this is ongoing, the lack of experienced Windows developers participating the Rust project has been slowing down the progress. We'll be very happy to get your contribution!

Python links the VC runtime (so not even the system CRT).

MinGW links the system CRT by default, which is one reason that it can be fussy to compile Python extensions with it.

(I'm more curious about what a survey would reveal than I am trying to argue with you about what you said)

Software originating on posix systems is most easily ported at the libc interface level, so it's natural to target some libc on Windows. But it usually creates awkwardness, either because of version dependencies, or the system libc not having everything they need and using some specific VC runtime, like you say.

I was a developer on the Delphi compiler for some years. Statically linked, a minimal Delphi executable had no dependencies other than the *32.dll libraries. And there is no system functionality that requires use of some libc, or significant duplication of effort. The Win32 API doesn't even use the C calling convention.

In theory you could later implement libc (libcrust. calling it now) in Rust as well so you get the best of both worlds couldn't you?

This is actually a project I have considered with in the past, though not very seriously. Theoretically you could completely replace libc with a Rust implementation and use it system-wide, and the rest of your programs would be none the wiser. It's a non-trivial amount of effort, however. :)

I'm not sure if it makes any sense to implement libc in anything other than C.

It would be an interesting experiment, seeing as how Rust code can be called from C and vice versa.

There's already been some tinkering on various operating system kernels written in Rust (even if they don't do much besides printing "Hello, world!" quite yet), so I figure a pure-Rust standard library is the next step in that.

Yes, but the standard crates don't really use any of the glibc specific Stuff. I found it not too difficult when I ported Rust to use `newlibc`, for use with PNaCl. I have even managed to build a PNaCl version of `rustc` itself.

> I recall something about Rust's libc crate being glibc-specific.

If this is true, it's because support for others hasn't rolled out yet, not because it has some inherent dependency on that version of libc.

Reply on news.ycombinator.com