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.

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

Add built-in support for *-linux-none targets #618

Merged
merged 5 commits into from
Mar 9, 2025
Merged

Conversation

newpavlov
Copy link
Member

@newpavlov newpavlov commented Mar 7, 2025

@newpavlov newpavlov requested a review from josephlr March 7, 2025 10:38
@@ -38,6 +38,9 @@ cfg_if! {
);
}
}
} else if #[cfg(all(target_os = "linux", target_env = ""))] {
Copy link
Member Author

@newpavlov newpavlov Mar 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically, we only have the x86_64-unknown-linux-none target, but to future-proof ourselves I think it's fine to use a more general cfg.

Theoretically, it's possible that a new linux-none target will be added for a target_arch which is not supported by linux_raw, but I think probability of it is really low and it can be safely ignored.

Copy link
Member

@josephlr josephlr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks reasonable, but should we add tests for this? I'm not sure if it's possible to build a x86_64-unknown-linux-none binary yet, but we could at least add a tier3 build test

@josephlr
Copy link
Member

josephlr commented Mar 9, 2025

We should also update the supported targets list in lib.rs, if you think this target deserves its own entry.

Copy link
Member

@josephlr josephlr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

I'd assume at this point there's no way to create a binary for x86_64-unknown-linux-none using rustix, so it's not possible to test right now?

@newpavlov
Copy link
Member Author

IIUC it should be possible to create an executable binary, but we would need to deal with the entry point ourselves. I think the existing linux_raw tests and the build-only job should be sufficient.

@newpavlov newpavlov merged commit a13ad84 into master Mar 9, 2025
71 checks passed
@newpavlov newpavlov deleted the linux_none branch March 9, 2025 17:46
@newpavlov newpavlov mentioned this pull request Mar 10, 2025
newpavlov added a commit that referenced this pull request Mar 17, 2025
### Added
- `efi_rng` opt-in backend [#570]
- `linux_raw` opt-in backend [#572]
- `.cargo/config.toml` example in the crate-level docs [#591]
- `getrandom_test_linux_without_fallback` configuration flag to test
that file fallback
  is not triggered in the `linux_android_with_fallback` backend [#605]
- Built-in support for `*-linux-none` targets [#618]
- Cygwin support [#626]

### Changed
- Update `wasi` dependency to v0.14 [#594]
- Add `#[inline]` attribute to the inner functions [#596]
- Update WASI and Emscripten links in the crate-level docs [#597]
- Do not use `dlsym` on MUSL targets in the
`linux_android_with_fallback` backend [#602]
- Remove `linux_android.rs` and use `getrandom.rs` instead [#603]
- Always use `RtlGenRandom` on Windows targets when compiling with
pre-1.78 Rust [#610]
- Internal representation of the `Error` type [#614]
- Remove `windows-targets` dependency and use [`raw-dylib`] directly
[#627]

### Removed
- `Error::INTERNAL_START` and `Error::CUSTOM_START` associated constants
[#614]

[#570]: #570
[#572]: #572
[#591]: #591
[#594]: #594
[#596]: #596
[#597]: #597
[#602]: #602
[#603]: #603
[#605]: #605
[#610]: #610
[#614]: #614
[#618]: #618
[#626]: #626
[#627]: #627
[`raw-dylib`]:
https://doc.rust-lang.org/reference/items/external-blocks.html?highlight=link#dylib-versus-raw-dylib
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants