-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
tests failing on macOS High Sierra #981
Comments
Thanks for the report! These sorts of things can change over time and it should be fine to tweak the values as they change. |
MacOS's libc, which is somewhere in their SDK, is not based on glibc, there are a lot of inconsistencies, such as different struct layouts, same consts with different values and so on. Maybe disable libc build for OS X entirely since it's not reliable in any way, unfortunately. Other then full sanity check and somewhat reimplemenation for OSX and probably BSD targets. |
This means that people can't target some SDK versions with libc. These constants changed again in xcode10. I can update them, but then people will stop being able to target xcode9.2 with them. What's worse is that if the std library use them as options to apple APIs, well depending on the system we might be calling APIs with different options =/ |
I've just hit a similar issue with 10.14 and NET_RT_MAXID (10 in git, 11 in 10.14). Does anyone know of a |
You might want to check the EDIT: that detects the xcode version of the system, but note that one can link to older SDK versions with it, so if you want to make these constants correct you need to "somehow" figure out the SDK version that the user is going to use (e.g. by checking the SDK env variables). |
Deprecate mach APIs: users should use the `mach` crate instead. See rust-lang#981, the mach APIs have breaking changes from MacOSX SDK release to release, and that's pretty much what the users are seeing here. We are currently not exposing that many `mach` APIs in `libc`, so this PR deprecates them, forwarding users to use the `mach` crate instead, which provides the mach user-space APIs, is tested against multiple SDK versions, handles removed/deprecated/breaking API changes/etc. Doing all of that in `libc` feels overkill. Closes rust-lang#981 .
Deprecate mach APIs: users should use the `mach` crate instead. See #981, the mach APIs have breaking changes from MacOSX SDK release to release, and that's pretty much what the users are seeing here. We are currently not exposing that many `mach` APIs in `libc`, so this PR deprecates them, forwarding users to use the `mach` crate instead, which provides the mach user-space APIs, is tested against multiple SDK versions, handles removed/deprecated/breaking API changes/etc. Doing all of that in `libc` feels overkill. Closes #981 .
This is from running the tests on my laptop.
failure output:
and here's the relevant snippet of my
/usr/include/mach/vm_statistics.h
of the conflicting VM_* constants. I'm not sure how to help with the syslog function pointer error, but happy to give more info as requested.The text was updated successfully, but these errors were encountered: