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 <[email protected]> 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 <[email protected]> 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
