Haiku: Initial work at OS support #36727
Conversation
* Hand rebased from Niels original work on 1.9.0
* Hand rebased from Niels original work on 1.9.0
The src/libstd/sys/unix/net.rs file depends on it. It is missing from Haiku. This workaround should actually 'fix' the problem, but it turns out the fds-are-cloexec.rs test hangs. I do not know how related these two issues are, but it warrants further investigation. The test is ignored on this platform for now. * Hand rebased from Niels original work on 1.9.0
* Hand rebased from Niels original work on 1.9.0
* Hand rebased from Niels original work on 1.9.0
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
| pub fn set_name(_name: &CStr) { | ||
| // Haiku has no way to set a thread name. | ||
| } | ||
|
|
There was a problem hiding this comment.
Can't this be merged with the above case?
|
@bors r+ |
|
📌 Commit 7c34d9c has been approved by |
Haiku: Initial work at OS support These changes should be non-invasive to non-Haiku platforms. These patches were hand reworked from Neil's original Rust 1.9.0 patches. I've done some style cleanup and design updates along the way. There are a few small additional patches to libc, rust-installer and compiler-rt that will be submitted once this one is accepted. Haiku can be compiled on Linux, and a full gcc cross-compiler with a Haiku target is available, which means bootstrapping should be fairly easy. The patches here have already successfully bootstrapped under our haiku x86_gcc2 architecture. http://rust-on-haiku.com/wiki/PortingRust I'll be focusing on our more modern gcc5 x86 and x86 architectures for now. As for support, we're not seeking official support for now. We understand Haiku isn't a top-tier OS choice, however having these patches upstream greatly reduces the amount of patchwork we have to do. Mesa has Haiku code upstream, and we submit patches to keep it going. Mesa doesn't test on Haiku and we're ok with that :-)
| @@ -279,7 +279,12 @@ impl DirEntry { | |||
| stat(&self.path()).map(|m| m.file_type()) | |||
| } | |||
|
|
|||
| #[cfg(not(target_os = "solaris"))] | |||
| #[cfg(target_os = "haiku")] | |||
There was a problem hiding this comment.
Shouldn't the haiku/solaris fallbacks here be the same?
brson
added
the
relnotes
|
cc @rust-lang/libs @rust-lang/tools |
These changes should be non-invasive to non-Haiku platforms. These patches were hand reworked from Neil's original Rust 1.9.0 patches. I've done some style cleanup and design updates along the way.
There are a few small additional patches to libc, rust-installer and compiler-rt that will be submitted once this one is accepted.
Haiku can be compiled on Linux, and a full gcc cross-compiler with a Haiku target is available, which means bootstrapping should be fairly easy. The patches here have already successfully bootstrapped under our haiku x86_gcc2 architecture. http://rust-on-haiku.com/wiki/PortingRust
I'll be focusing on our more modern gcc5 x86 and x86 architectures for now.
As for support, we're not seeking official support for now. We understand Haiku isn't a top-tier OS choice, however having these patches upstream greatly reduces the amount of patchwork we have to do. Mesa has Haiku code upstream, and we submit patches to keep it going. Mesa doesn't test on Haiku and we're ok with that :-)