-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
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
Update macOS frameworks to 10.12 #47678
Conversation
Success on aarch64-linux (full log) Attempted: coreutils, krb5, patch The following builds were skipped because they don't evaluate on aarch64-linux: darwin.hfs, darwin.xnu Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: coreutils, krb5, patch The following builds were skipped because they don't evaluate on x86_64-linux: darwin.hfs, darwin.xnu Partial log (click to expand)
|
@@ -790,6 +790,8 @@ _removexattr | |||
_rename | |||
_rename_ext | |||
_renameat | |||
_renamex_np | |||
_renameatx_np |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these available on 10.12 and earlier?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like they were introduced in xnu-3789.70.16 which corresponds to 10.12. gnulib uses it since this commit:
and from updating to latest xnu:
Here is the file that defines it in XNU:
http://newosxbook.com/src.jl?tree=xnu-3789.70.16&file=/libsyscall/wrappers/renamex.c
I wonder what people think about breaking support for 10.10 and 10.11? How common are they in the wild?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well 10.12 is pretty important because I'm pretty sure most builders are still running that. We probably don't have to keep older versions, but we should officially drop support for those then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was working on automating the generation of those symbol lists as a step towards #23432
https://github.com/veprbl/libsystem_symbol_list/branches <- tool to collect lists
https://github.com/veprbl/nixpkgs/commits/libsystem_symbols <- branch intended for the PR, includes the lists and scripts to take intersection
I was never able to dedicate CPU time to bootstrap this before making a PR, but if someone would be interested in picking this up, feel free :)
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@veprbl Were there any issues with this method? Might be worth putting in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a 10.12.6 branch in libsystem_symbol_list that was acquired from Travis machine. It would be nice to have a volunteer to contribute a list for 10.14.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matthewbauer Not that I know of. In the end of the day you just get a list and the rest of the machinery stays the same. You are not able to easily edit it, but its content have a clear motivation. And you also recover some missing symbols that used to be skipped in manually maintained list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I just cherry-picked these and am doing a mass rebuild. We'll see how it works...
Timed out, unknown build status on x86_64-darwin (full log) Attempted: coreutils, darwin.hfs, darwin.xnu, krb5, patch Partial log (click to expand)
|
This will enable finally modern tools like chunkwm to be packaged 💯 |
Yeah, I think so. |
This is mostly great, but it doesn't feel like nixpkgs is really the place to keep the archive of all libsystem symbol versions, especially when those files aren't actually used in the evaluation of nixpkgs (just as input to a script that produces the final intersected list). Perhaps we could just shove them into a separate repo in the NixOS org? |
Also, this should probably go to staging |
Yeah, I'd probably send it to staging and maybe even trigger a PR job in Hydra for it, since it can have pretty far-reaching implications and it'd be nice to not be surprised by them. |
This shouldn't go to staging before we run a wip jobset, I want to have an idea of the impact before polluting staging with potentially problematic changes. |
fdbf496
to
9b9046f
Compare
What's the status here? The only regression I noticed when running a small set of builds was |
I would be happy to grt this merged. I haven’t had time to really clean this up and stuff. Mostly someone will need to be around if there are any regressions. I think the only notable change this brings is that macOS 10.11 will no longer work properly. I am still working on getting securitytool to build. But it’s gotten a lot harder than i expected. |
We should definitively move the symbols to a separate repo, but we don't have to wait for that to test it further. I would propose to rebase against a hydra eval (eg. 206a1c0 for trunk 1490895) and start off a darwin eval. |
9b9046f
to
09399d1
Compare
Timed out, unknown build status on x86_64-darwin (full log) Attempted: xcbuild Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: xcbuild The following builds were skipped because they don't evaluate on x86_64-linux: darwin.dtrace, darwin.libpthread Partial log (click to expand)
|
Timed out, unknown build status on x86_64-darwin (full log) Attempted: darwin.dtrace, darwin.libpthread, xcbuild Partial log (click to expand)
|
@GrahamcOfBorg eval |
@LnL7 this should be ready to go! I haven't looked at it in a while, so will need someone to go through this again just to make sure it doesn't mess anything up. I was originally planning to include fixes for "securitytool" in here - but haven't gotten it to work. But otherwise this should be safe to go to staging I think. |
Both coreutils and patch are failing for me, but this looks promising Homebrew/homebrew-core@440b9e7. Looks like we didn't run into that yet because we keep the sdk versions stable.
|
Does that happen on 10.12??? I have a 10.11 machine that it breaks on but I was hoping that would be the only one broken. I don't get it on 10.14 |
Yeah, this is 10.12. Does this not happen on newer versions? |
Yeah - I'm surprised it happens on 10.12. The symbol was added by Apple recently: http://newosxbook.com/src.jl?tree=xnu-3789.70.16&file=/bsd/sys/stdio.h But it should be there for 10.12. Maybe it needs it listed in the symbols list? |
83d4a73
to
716f9fb
Compare
Sorry the original commit was missing the new symbols to libSystem. That error should be fixed in 716f9fb. Going to do a rebuild and then merge. |
1ad60a8
to
a7bf961
Compare
Lots of stuff has gotten moved around. Many security libraries have been merged into the Security monorepo. I’ve cleared them out for now, we will need to modify Security to build them! This also moves some things around to more clearly separate bootstrapping the stdenv from everything else. We want the “normal” mode to be the non-bootstrapped version. When you ask for “Security”, you want the actual built software, not a crippled one. - Add TARGET_OS_OSX to darwin.libSystem. Looks like something introduced in 10.12. TARGET_OS_MAC is only set when building for desktop (iOS will have TARGET_OS_MAC set) - Bump darwin.dtrace - Bump darwin.libpthread - Remove SmartCardServices, libsecurity*, etc. - Install some more headers for darling.
a7bf961
to
e6f7f29
Compare
Like I mentioned before, this should be tested on hydra before merging to staging. It causes 8600 breakages and the stdenv is still broken on 10.12 and thus will block the new staging-next until fixed or reverted. https://hydra.nixos.org/eval/1496326#tabs-now-fail
|
Sorry about that! It's very weird that this is not happening locally. Most likely we can remove those entries from system_kernel_symbols safely. The symbols should be available on 10.12.6 but perhaps not on earlier 10.12. |
The VM was installed with 10.12.2, looks like it's much better after updating which is a bit unfortunate but not as bad as I thought. Can you look into the binutils issue? I'll start another eval when that's fixed to see what remains. |
hfs was introduced in e6f7f29 (NixOS#47678), but it seems nobody will needs its pure headers. We drop it from Libsystem.
Motivation for this change
Lots of updates to Darwin stuff are now possible following @copumpkin's update in #46704.
A few things I want to get to:
Update Security/SecurityTool