rust 1.39 and errno

[Antonio Huete Jiménez]

Hi guys,

Chuck, I'm going to create a Rust wiki entry with all the information  
on how to build it and the known issues we have right now.
Zach, I think I'm going to give the bounty a try. I am just learning  
Rust so if there is somebody interested in the bounty that has more  
experience with Rust, let me know.

Regards,
Antonio Huete


Zachary Crownover <zachary.crownover at gmail.com> escribió:

> 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.
>
> 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?
>>
>> - 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,
>>
>> Chuck