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

Fix nix for Dragonfly #684

Closed
wants to merge 4 commits into from
Closed

Fix nix for Dragonfly #684

wants to merge 4 commits into from

Conversation

mneumann
Copy link
Contributor

No description provided.

mneumann added 4 commits July 17, 2017 22:37
Function __dfly_error() is gone from Rust since a long time. Rust's libstd uses
the thread_local attribute for errno, but thread_local cannot be used
from stable Rust. For this reason I created errno_dragonfly which is
a C FFI wrapper for errno.
@@ -27,6 +27,9 @@ bitflags = "0.9"
cfg-if = "0.1.0"
void = "1.0.2"

[target.'cfg(target_os = "dragonfly")'.dependencies]
errno-dragonfly = "0.1"
Copy link
Member

Choose a reason for hiding this comment

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

We shouldn't need an extra crate just for this. The basic symbols should all be defined in libc, and nix's won src/errno.rs defines errno_location. Can you merge whatever you need into nix and libc so we don't depend on the extra crate?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, there is no other possibility!!! I talked with @alexcrichton to make the thread_local attribute attribute stable, and he actually suggested me to write a C extension like errno-dragonfly. libc does not expose the errno variable directly AFAIK.

The problem is that in DragonFly, the errno variable is not a global, but a thread locale variable, so a simple "extern __errno" as used by the other OSes simply does not work. In libstd, errno can be accessed by using "#[thread_local]", as unstable features are allowed for libstd.

If you want to support DragonFly there really isn't any other option to go via C atm.

Copy link
Member

Choose a reason for hiding this comment

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

That's ... sad. I took a stab at this myself. It doesn't look as though we can use #[thread_local] unless we enable it for all builds, not just Dragonfly's. Still, what would you say to moving the C extension into Nix instead of making it its own crate? Cargo just seems like an awfully heavyweight way to manage such a tiny amount of code.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't have a problem with this crate staying external, though I'd much rather rely on a crate that had proper semver (i.e. was 1.0+).

@@ -20,7 +20,10 @@ pub type type_of_cmsg_len = socklen_t;
#[cfg(target_os = "macos")]
pub type type_of_cmsg_data = c_uint;

#[cfg(not(target_os = "macos"))]
#[cfg(target_os = "dragonfly")]
Copy link
Member

Choose a reason for hiding this comment

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

I think this should be #[cfg(any(target_os = "dragonfly", target_os = "macos"))]

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, this is correct! type_of_cmsg_data is already defined above as c_uint. Here it is defined for DragonFly as c_int. Below it is defined for all other OSes.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, you're right. I didn't notice the "u".

@@ -145,27 +145,34 @@ mod status {
target_os = "netbsd"))]
mod status {
use sys::signal::Signal;
use libc::c_int;
Copy link
Member

Choose a reason for hiding this comment

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

Why is it necessary to change all of these types?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't understand why you use i32 here instead of c_int. The latter is the correct type for those APIs, as waitpid returns a c_int, not a i32. On most platforms these types are identical, but c_int should be the correct one.

Copy link
Member

Choose a reason for hiding this comment

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

Sure, if you want to be pedantically correct. But it's got nothing to do with DragonFly. It you're going to change those types, please do it in a separate commit, not comingled with DragonFly specific changes.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with @asomers here, please remove this changes from this PR.

@Susurrus
Copy link
Contributor

There's big changes coming to the FFI declarations in the socket module in #647. I suggest you test that PR first and provide edits there and keep this PR rebased on top of it so it can be merged afterwards.

@mneumann
Copy link
Contributor Author

Ok, I will wait for #647 to land, then rebase on top of that.

}

#[cfg(not(target_os = "dragonfly"))]
pub fn signaled(status: c_int) -> bool {
wstatus(status) != WSTOPPED && wstatus(status) != 0 && status != 0x13
Copy link
Member

Choose a reason for hiding this comment

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

What does the magic number 0x13 mean? This sounds like a constant that should be in libc.

@@ -145,27 +145,34 @@ mod status {
target_os = "netbsd"))]
mod status {
use sys::signal::Signal;
use libc::c_int;
Copy link
Member

Choose a reason for hiding this comment

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

Sure, if you want to be pedantically correct. But it's got nothing to do with DragonFly. It you're going to change those types, please do it in a separate commit, not comingled with DragonFly specific changes.

@Susurrus
Copy link
Contributor

Susurrus commented Aug 1, 2017

@mneumann Do you want to rebase this and address @asomers review now that #647 landed?

@Susurrus
Copy link
Contributor

@mneumann I'd like to go ahead and get these changes except the errno-dragonfly parts merged. We can open that as an issue and defer on resolving it for now. Do you have time coming up here to address this?

@Susurrus
Copy link
Contributor

@mneumann I think I'd be fine with errno-dragonfly being a dependency of nix, as I'd like to get this merged. Please remove some of the unnecessary int -> i32 changes you have and rebase and let's get this merged!

@mneumann mneumann mentioned this pull request Nov 17, 2017
@mneumann
Copy link
Contributor Author

Closing in favor of #799

@mneumann mneumann closed this Nov 17, 2017
bors bot added a commit that referenced this pull request Dec 19, 2017
799: Fix nix on Dragonfly r=Susurrus a=mneumann

This commit replaces pull request #684. It fixes building `nix` on DragonFly. All tests pass. This requires most recent libc to build: rust-lang/libc#851.
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.

3 participants