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

tests failing on macOS High Sierra #981

Closed
mcginty opened this issue Apr 23, 2018 · 5 comments · Fixed by #1364
Closed

tests failing on macOS High Sierra #981

mcginty opened this issue Apr 23, 2018 · 5 comments · Fixed by #1364

Comments

@mcginty
Copy link
Contributor

mcginty commented Apr 23, 2018

This is from running the tests on my laptop.

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.13.4
BuildVersion:   17E199

failure output:

bad syslog function pointer: rust: 140734611868871 (0x7fff548c4cc7) != c 140734611869453 (0x7fff548c4f0d)
bad VM_FLAGS_USER_ALLOCATE value at byte 0: rust: 27 (0x1b) != c 31 (0x1f)
bad VM_FLAGS_USER_MAP value at byte 0: rust: 27 (0x1b) != c 31 (0x1f)

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.

/* These are the flags that we accept from user-space */
#define VM_FLAGS_USER_ALLOCATE	(VM_FLAGS_FIXED |		\
				 VM_FLAGS_ANYWHERE |		\
				 VM_FLAGS_PURGABLE |		\
				 VM_FLAGS_4GB_CHUNK |		\
				 VM_FLAGS_RANDOM_ADDR |		\
				 VM_FLAGS_NO_CACHE |		\
				 VM_FLAGS_OVERWRITE |		\
				 VM_FLAGS_SUPERPAGE_MASK |	\
				 VM_FLAGS_ALIAS_MASK)
#define VM_FLAGS_USER_MAP	(VM_FLAGS_USER_ALLOCATE |	\
				 VM_FLAGS_RETURN_4K_DATA_ADDR |	\
				 VM_FLAGS_RETURN_DATA_ADDR)
@alexcrichton
Copy link
Member

Thanks for the report! These sorts of things can change over time and it should be fine to tweak the values as they change.

@dpogretskiy
Copy link

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.

@gnzlbg
Copy link
Contributor

gnzlbg commented Oct 29, 2018

Thanks for the report! These sorts of things can change over time and it should be fine to tweak the values as they change.

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 =/

@palfrey
Copy link
Contributor

palfrey commented Nov 20, 2018

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 cfg! way or similar to match a OS X version?

@gnzlbg
Copy link
Contributor

gnzlbg commented Nov 20, 2018

You might want to check the mach crate. It has a mach-test crate inside like libc-test crate, which contains some code for detecting the osx version and using that with ctest: https://github.com/fitzgen/mach/blob/master/mach-test/build.rs#L4

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).

gnzlbg added a commit to gnzlbg/libc that referenced this issue May 24, 2019
gnzlbg added a commit to gnzlbg/libc that referenced this issue May 25, 2019
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 .
bors added a commit that referenced this issue May 25, 2019
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 .
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants