Success on x86_64-linux (full log)

Attempted: pbzx

building
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/q0mh5f5kknx83kz55k433qb4diyas2h1-pbzx-1.0.2
shrinking /nix/store/q0mh5f5kknx83kz55k433qb4diyas2h1-pbzx-1.0.2/bin/pbzx
strip is /nix/store/fzcs0fn6bb04m82frhlb78nc03ny3w55-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/q0mh5f5kknx83kz55k433qb4diyas2h1-pbzx-1.0.2/bin
patching script interpreter paths in /nix/store/q0mh5f5kknx83kz55k433qb4diyas2h1-pbzx-1.0.2
checking for references to /build in /nix/store/q0mh5f5kknx83kz55k433qb4diyas2h1-pbzx-1.0.2...
/nix/store/q0mh5f5kknx83kz55k433qb4diyas2h1-pbzx-1.0.2

Success on aarch64-linux (full log)

Attempted: pbzx

building
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/9jrxag340gkh1w9pnzr039f55b7y56ar-pbzx-1.0.2
shrinking /nix/store/9jrxag340gkh1w9pnzr039f55b7y56ar-pbzx-1.0.2/bin/pbzx
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/9jrxag340gkh1w9pnzr039f55b7y56ar-pbzx-1.0.2/bin
patching script interpreter paths in /nix/store/9jrxag340gkh1w9pnzr039f55b7y56ar-pbzx-1.0.2
checking for references to /build in /nix/store/9jrxag340gkh1w9pnzr039f55b7y56ar-pbzx-1.0.2...
/nix/store/9jrxag340gkh1w9pnzr039f55b7y56ar-pbzx-1.0.2

Success on x86_64-darwin (full log)

Attempted: pbzx

patching sources
configuring
no configure script, doing nothing
building
installing
post-installation fixup
strip is /nix/store/vb6mgjqgd9h11nbv60fvrp1ls9nxck2y-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/wy1zyd4b3bxcz8h6q07skszfidxbz7ld-pbzx-1.0.2/bin
patching script interpreter paths in /nix/store/wy1zyd4b3bxcz8h6q07skszfidxbz7ld-pbzx-1.0.2
/nix/store/wy1zyd4b3bxcz8h6q07skszfidxbz7ld-pbzx-1.0.2

Oops looks like we'll need to bump apple-source-releases as well.

Last time I tried to even take it to 10.11 we failed because our CF was too old (and really painful to update), and lots of apple headers use CF macros that aren't in our release. Has that changed somehow?

We have this now:

https://github.com/apple/swift-corelibs-foundation/tree/master/CoreFoundation

But I was actually hoping we could get away with updating the SDK without actually touching the stdenv- is that possible?

Not as far as I know 😦

Also, that swift-corelibs-foundation is something I put a lot of effort against but unfortunately it's also not a drop-in replacement unless something's changed in the past few months. The issue is that their default build produces a static library (I might have even put a package up for it on nixpkgs) but it delegates allocation out to the swift allocator, and doesn't seem to make it easy to plug in a different allocator. So it's the spiritual successor to the CF opensource releases (and actually includes more functionality than they did), but also assumes a bit of Swift runtime which I'm reluctant to bundle into our bootstrap.

I also tried this a while back and ran into issues with CF, the impure version should only be used is a last resort.
What I did think about is the idea of providing the 10.11 or 10.12 frameworks next the the current ones.

What I did think about is the idea of providing the 10.11 or 10.12 frameworks next the the current ones.

Frameworks should be backwards compatible, though right? Some of the 10.11/10.12 frameworks break occasionally because of incompatibilities with libSystem headers (trying to fix with 6c12e54). Still waiting for stdenv to build but I suspect I'll run into problems soon with the out of date CoreFoundation though (but maybe there haven't been any breaking changes since 1153.18).

Not necessarily, I couldn't build anything useful with CF 10.10 and 10.11 frameworks. It might be possible but I'm guessing that requires reshuffling some stuff in the stdenv to make the distinction between the pure/impure CF more clear, currently it's included implicitly IIRC.

The implicit include might have been a bad call, TBC. It's just that so much stuff just assumes it exists if you're on macOS (even plain unixy tools often) that the number of conditionals got ridiculous.

Closing for now because this definitely looks like a dead end.

Sorry, hope it's not because I haven't been able to pay much attention to it. I've been quite busy! In principle I want this to happen but can't really think through the implications of doing the CF substitution you're proposing right now 😦

No problem. The biggest problem is that even after doing "impure" CF we still have out of date Libsystem, etc.

Actually i see we are using Libsystem-1226.10.1 for the headers and apple open source releases provides 1238.60.2 on macOS 10.12 and 1252 on macOS 10.13. Maybe we can give it another try with Impure-CF?
AFAIK CF-Releases are 3 macOS-Releases delayed, i wouldn't hope here anymore.

I'm playing around with updating macOS 10.12 packages on top of @matthewbauer 's branch. Fixed a couple of builds so far. Compiling has been going on for a while. Is this an approach that could even work? CF is still missing from the open source release. I pinged Apple about it.

Ended up getting stuck with the new configd. It tries to include files from macOS SDK. And if I try to depend on apple-sdk.sdk.out I get an infinite recursion error. Any tips on how to debug it?

Now that I have a sorta working new CF, I'm going to try to get this integrated. I'd rather the commit that enables it (and in some ways also depends on this change) be atomic though, so I'll give you credit in the commit message @matthewbauer but probably won't preserve the commit itself