rust 1.39 and errno

Chuck Musser cmusser at
Fri Dec 27 21:05:10 PST 2019

I attempted to compile Rust 1.39.0 using the bootstrap repo 
( Tuxillo is 
probably already working on this, but I wanted to see if I could 
understand the process. I didn't get very far.

After making mods that were pretty obvious (adding checksums, a 
subdirectory for the new version, etc.), the build failed when compiling 
the getrandom crate. The error was:

error[E0432]: unresolved import `libc::__error`
22 | use libc::__error as errno_location;
| ^^^^^^-------^^^^^^^^^^^^^^^^^^
| | |
| | help: a similar name exists in the module: `ferror`
| no `__error` in the root

Support for the error variable is somehow tied up in "thread local 
storage". I have a vague understanding that every thread has its own 
copy of the (traditonally global) errno variable, but I don't understand 
what the implications are for supporting it in Rust. There's a tracking 
issue in Rust regarding thread local storage, so it's obviously a 
non-trivial feature. That issue is

There was a commit to the Rust libc a while back that purported to add 
support for a function called __errno_location() for various OSes, but I 
think it didn't actually do that for DragonFly. It did add __error, but 
not __errno_location(). This was back in July and I don't think such a 
function actually existed. The pull request was

More recently, there was a commit to DragonFly itself that did add 
__errno_location, so presumably the Rust libc could now really use it. 
That commit was

I'd like to gain a better understanding of how all this stuff works. For 

- The compile failure says that libc::__error does not exist, but the 
libc included in the source does seem to have it defined. Is it 
unavailable because thread local storage is disabled?

- Why does the __errno_location() function need to exist? It must differ 
somehow from the __error() function.

- As of right now, __errno_location() may only exist in nightly, so I'm 
assuming that if Rust's libc glue got updated to reference it, it would 
only work correctly for dfly nightlies after that point, and any 
subsequent releases (5.8+). Is that correct?

- Many prior version of rustc have been successfuly built for DragonFly. 
Did those have something that avoided the use of errno, or is getrandom 
a new addition to the build and that's why it's failing?

Thanks for any insight on this stuff,


More information about the Users mailing list