rust 1.39 and errno

[Michael Neumann]

On Fri, Dec 27, 2019 at 10:26:27PM -0800, Zachary Crownover wrote:
> The libc crate on dfly is very hit or miss. We’re a tier III platform for Rust which basically means maybe it builds maybe it doesn’t but there’s some code in the base to sort of try but commits have no requirement to pass any builds against it to be accepted. With that, one point release might build for dfly and one point release off might not. Another thing is that what you build and what you depend on can have varying version requirements, so any number of things potentially pulling in libc could be pulling a different version and that version has a decent chance of not building. From my experience that’s been the biggest pain point of doing any Rust development on dfly. There is a code bounty on www.dragonflybsd.org for getting a consistent working build of libc for Rust. I don’t know if more incentive on it would be entice more work, but I maintain hope. 

The Rust libc worked quite well a while ago. The thread_local attribute
seems to be still unstable, so it can't be included by default into libc
or Rust. That's why I created the errno-dragonfly crate
(https://crates.io/crates/errno-dragonfly) that uses a C extension. Some
other crates use it IIRC (e.g. nix). For bootstrapping Rust, this is
less of an issue as there you can use unstable features, but for
productive use, you often want to use only stable Rust features.

I think you need to enable the "unstable" feature flag for libc when
bootstrapping rust. See line 57 ff of build.rs:

https://github.com/rust-lang/libc/commit/3fa021d7ab36b59e877082d3150d626afabc8454#diff-01aac9db881a5c69461883f5c701824c

The reason why Rust stopped to compile probably lies in some added code
to the getrandom crate (maybe some derived code from FreeBSD).

Please always take a look at the rust port in Ravenports (1.40):

https://github.com/jrmarino/ravensource/tree/master/bucket_7B/rust/patches

Especially this patch is of interest:

https://github.com/jrmarino/ravensource/blob/master/bucket_7B/rust/patches/patch-vendor_libc_src_lib.rs

The important part is to use #![feature(thread_local)] unconditionally!
It will probably start to work once you add this patch.

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

If you have __errno_location(), you should be able to derive __error()
from it, simply by dereferencing the pointer.

> > - 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?

__error() will return the errno integer value, while __errno_location()
will return a pointer to the errno variable.

Hope this helps! If anyone can try this out, I would be really glad.

Regards,

  Michael


> http://www.dragonflybsd.org/docs/developer/Code_Bounties/
> 
> > On Dec 27, 2019, at 21:05, Chuck Musser <cmusser at sonic.net> wrote:
> > 
> > I attempted to compile Rust 1.39.0 using the bootstrap repo (https://github.com/DragonFlyBSD/rust-bootstrap-dragonfly). 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`
> > --> /home/chuck/src/build-1.39/rustc-1.39.0-src/vendor/getrandom/src/util_libc.rs:22:13
> > |
> > 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 https://github.com/rust-lang/rust/issues/29594
> > 
> > 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 https://github.com/rust-lang/libc/pull/1432/.
> > 
> > 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 https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/60d311380ff2bf02a87700a0f3e6eb53e6034920
> > 
> > I'd like to gain a better understanding of how all this stuff works. For starters:
> > 
> > - 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?
> > 
 > 
> > - 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,
> > 
> > Chuck

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de