macOS libSystem and other libraries haven't been updated since macOS Sierra

[hauleth]

Describe the bug

libSystem used to build packages is highly outdated.

To Reproduce

Build any package that is trying to call futimens function on macOS, for example Zig 0.6.

Expected behavior

Such package should build.

Additional context

Apple published code for libraries for macOS up to 10.15.1 - https://opensource.apple.com

Notify maintainers

There is no meta.maintainers but @volth was last one that touched that file.

Metadata

• system: "x86_64-darwin"
• host os: Darwin 18.7.0, macOS 10.14.6
• multi-user?: no
• sandbox: no
• version: nix-env (Nix) 2.3.4
• channels(hauleth): "darwin, nixpkgs-20.09pre221814.10100a97c89"
• nixpkgs: /Users/hauleth/.nix-defexpr/channels/nixpkgs

[hauleth]

Ok, found maintainers - @copumpkin @gridaphobe

[matthewbauer]

We are intentionally behind on the base system libraries so that systems not on Catalina still work. This is the equivalent of setting MACOSX_DEPLOYMENT_TARGET=10.12 in XCode.

I would consider this partly a bug in Zig or other software - they should be able to provide a fallback if futimens or other symbols don't exist.

We might be able to update libSystem to macOS High Sierra (10.13), though. It's possible that futimens is included there. It looks like only about 5% of users are still on macOS Sierra:

https://gs.statcounter.com/macos-version-market-share/desktop/worldwide

[hauleth]

It is not a bug and 10.13 would work.

[bouk]

I just ran into this too—upgrading libSystem to High Sierra would seem to fix this.

[happysalada]

Almost a year later it looks like the share of macos sierra dropped to 3.5%, Can we consider an upgrade?

[Artturin]

2.71% now

[happysalada]

From what I gathered from different places, I don't think anybody is against upgrading, the problem is making the actual upgrade.
Some people are involved in trying to do the upgrades, however you need lots of time, esoteric knowledge and luck it seems.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/changing-the-stdenv-on-x86-64-darwin-to-use-the-apple-command-line-tools/16593/1

[arximboldi]

Is there a way to workaround this locally for the nix shell without rebuilding all of nixpkgs?

[Atemu]

@arximboldi I think you're having a different issue, open a new one.

[arximboldi]

@Atemu, I think I mean this one.

I am developing some software for Linux and Mac where I am using Nix to create the development environment.

I am bringing the compiler and MacOS frameworks via the nix shell (I use darwin.apple_sdk.frameworks... as dependency on Mac). However, when I try to use some API's that are newer than 10.12 I am having errors.

I think that this is caused by this issue. Plus the fact that somehow the CC wrapper is adding --min-macos-version=10.12 on Daring systems. Normally I would use some sort of override or overlay combination to work around outdated stuff in nixpkgs, but I am not sure how to do this for MacOS frameworks, since they seem to be brought in in very special ways with a fair amount of magic. I think the min-macos-version flag can maybe be changed by using a cross-system or changing the targetSystem in the CC, but it's still not 100% clear...

[Atemu]

If it could be done with overrides, it'd be done upstream instead. The problem is actually packaging the newer versions which you'd have to do with overrides aswell and that's extremely hard.

[sheldonneuberger-sc]

I think that this is caused by this issue. Plus the fact that somehow the CC wrapper is adding --min-macos-version=10.12 on Daring systems

If you run unset MACOSX_DEPLOYMENT_TARGET (you can put it in shellHook if you have a shell.nix), it should fix this issue, but you'll still need to compile against a new xcode instead of the CC inside the nix shell.

[aviallon]

Closed by #346043