Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add GNU/Hurd support #370

Merged
merged 1 commit into from
Nov 7, 2023
Merged

Add GNU/Hurd support #370

merged 1 commit into from
Nov 7, 2023

Conversation

sthibaul
Copy link
Contributor

No description provided.

@josephlr
Copy link
Member

Could we have a link to GNU/Hurd's documentation (for both urandom and the errno location). We should also add it to the list of targets in the CI

@sthibaul
Copy link
Contributor Author

sthibaul commented Sep 21, 2023 •
edited
Loading

Well, the Hurd doesn't really document it since it's just following GNU's interface. At best we can link to the implementation:

@sthibaul
Copy link
Contributor Author

Concerning the CI, the patches needed to build rustc and std are not finished committing in the various repositories. Actually getrandom is one of them :) so we have a chicken-and-egg issue if CI needs to be included before support is included

newpavlov
newpavlov approved these changes Sep 21, 2023
View reviewed changes
src/lib.rs Outdated Show resolved Hide resolved
@josephlr
Copy link
Member

josephlr commented Sep 22, 2023 •
edited
Loading

Concerning the CI, the patches needed to build rustc and std are not finished committing in the various repositories. Actually getrandom is one of them :) so we have a chicken-and-egg issue if CI needs to be included before support is included

For new targets, we don't require that Rust ships a libstd or libcore for that target (much less require that Rust have Host Tools for the target). This is due both to the chicken-and-egg problem you describe and because some targets which we support (like x86_64-wrs-vxworks or aarch64-apple-tvos) do not have libstd support.

However, provided that Rust supports your compiler target, we can still test them. See here.

However, it looks like rust-lang/rust#115230 is merged. The change we needed from that was adding support for i686-unknown-hurd-gnu to the compiler. We should be able to add this target to our Tier-3 tests once that PR hits nightly. @sthibaul do you know if it's possible to link rust binaries for GNU/Hurd on GNU/Linux?

@sthibaul
Copy link
Contributor Author

do you know if it's possible to link rust binaries for GNU/Hurd on GNU/Linux?

Yes it is possible, but as usual one needs to have the GNU/Hurd libc.so etc. at hand to be able to link. One can relatively easily build them from glibc's scripts/build-many-glibcs.py.

@josephlr
Copy link
Member

josephlr commented Sep 22, 2023 •
edited
Loading

do you know if it's possible to link rust binaries for GNU/Hurd on GNU/Linux?

Yes it is possible, but as usual one needs to have the GNU/Hurd libc.so etc. at hand to be able to link. One can relatively easily build them from glibc's scripts/build-many-glibcs.py.

I was able to compile a C program for HURD (with Clang) on my Debian Box by just installing gcc-multilib, so I'm hopeful we can also get it to work w/ Rust.

@josephlr
Copy link
Member

josephlr commented Sep 22, 2023 •
edited
Loading

Well, the Hurd doesn't really document it since it's just following GNU's interface. At best we can link to the implementation:

If Hurd is just implementing glibc interfaces, does it have support for getrandom or getentropy (which are part of glibc)? If those APIs exist, we should use them instead of the file-based APIs (as the file APIs can sometimes cause problems/toil).

@josephlr
Copy link
Member

josephlr commented Sep 22, 2023 •
edited
Loading

Well, the Hurd doesn't really document it since it's just following GNU's interface. At best we can link to the implementation:

If Hurd is just implementing glibc interfaces, does it have support for getrandom or getentropy (which are part of glibc)? If those APIs exist, we should use them instead of the file-based APIs (as the file APIs can sometimes cause problems/toil).

It looks like getrandom is implemented for Hurd it was added here in 2019, so it's probably fine to unconditionally depend on it.

We should have the docs link to the glibc man page: https://www.gnu.org/software/libc/manual/2.38/html_mono/libc.html#index-getrandom

EDIT: It seems like the implementation also involves opening a file (I think), but it also seems to have some other complicated logic. I think to be safe we should use glibc's getrandom.

@josephlr
Copy link
Member

I think this PR is also blocked on libc support, see rust-lang/libc#3325 (comment)

@sthibaul
Copy link
Contributor Author

do you know if it's possible to link rust binaries for GNU/Hurd on GNU/Linux?

Yes it is possible, but as usual one needs to have the GNU/Hurd libc.so etc. at hand to be able to link. One can relatively easily build them from glibc's scripts/build-many-glibcs.py.

I was able to compile a C program for HURD (with Clang) on my Debian Box by just installing gcc-multilib, so I'm hopeful we can also get it to work w/ Rust.

I guess your toolchain was then using linux's 32bit libc, so while this indeed exercises a hurd build, the actual linked result is a Linux binary, not a Hurd binary :)

@sthibaul
Copy link
Contributor Author

Well, the Hurd doesn't really document it since it's just following GNU's interface. At best we can link to the implementation:

If Hurd is just implementing glibc interfaces, does it have support for getrandom or getentropy (which are part of glibc)? If those APIs exist, we should use them instead of the file-based APIs (as the file APIs can sometimes cause problems/toil).

Ok, done so!

@sthibaul
Copy link
Contributor Author

(the mips failure is unrelated)

@josephlr
Copy link
Member

josephlr commented Oct 2, 2023

(the mips failure is unrelated)

Should be fixed by #372

@sthibaul
Copy link
Contributor Author

sthibaul commented Oct 8, 2023

I rebased on top of #372, and added std=core for now (building std depends on libc dep bump in rustc)

@sthibaul
Copy link
Contributor Author

sthibaul commented Oct 8, 2023

The netbsd build failure is unrelated

@josephlr
Copy link
Member

Well, the Hurd doesn't really document it since it's just following GNU's interface. At best we can link to the implementation:

If Hurd is just implementing glibc interfaces, does it have support for getrandom or getentropy (which are part of glibc)? If those APIs exist, we should use them instead of the file-based APIs (as the file APIs can sometimes cause problems/toil).

Ok, done so!

It seems like this current PR doesn't use the getrandom API, we should use that API if possible.

@josephlr
Copy link
Member

The netbsd build failure is unrelated

Yep, it's caused by cross-rs/cross#1345

@sthibaul
Add GNU/Hurd support
c96bfff 
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
@sthibaul
Copy link
Contributor Author

Well, the Hurd doesn't really document it since it's just following GNU's interface. At best we can link to the implementation:

If Hurd is just implementing glibc interfaces, does it have support for getrandom or getentropy (which are part of glibc)? If those APIs exist, we should use them instead of the file-based APIs (as the file APIs can sometimes cause problems/toil).

Ok, done so!

It seems like this current PR doesn't use the getrandom API, we should use that API if possible.

Indeed, fixed so.

@sthibaul
Copy link
Contributor Author

sthibaul commented Nov 5, 2023

Any news on this, is there still something missing?

@newpavlov newpavlov merged commit 8476c44 into rust-random:master Nov 7, 2023
47 of 48 checks passed
@newpavlov
Copy link
Member

Thank you! The CI failure is not relevant to this PR, so we can ignore it.

@newpavlov newpavlov mentioned this pull request Nov 7, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@newpavlov newpavlov newpavlov approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@sthibaul @josephlr @newpavlov