Skip to content

darwin.libffi: match upstream configuration on x86_64-darwin#383376

Merged
reckenrode merged 1 commit intoNixOS:stagingfrom
reckenrode:push-kqrzruxywypy
Feb 22, 2025
Merged

darwin.libffi: match upstream configuration on x86_64-darwin#383376
reckenrode merged 1 commit intoNixOS:stagingfrom
reckenrode:push-kqrzruxywypy

Conversation

@reckenrode
Copy link
Contributor

The headers for the system libffi enable the legacy closure API by default, which some packages (such as Python) expect.

Note: I only confirmed that Python built in the bootstrap.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@ofborg ofborg bot added the 6.topic: darwin Running or building packages on Darwin label Feb 19, 2025
@nix-owners nix-owners bot requested review from emilazy and toonn February 19, 2025 13:18
@github-actions github-actions bot added 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. labels Feb 19, 2025
Comment on lines 73 to 75
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should just install darwin/include wholesale rather than (or in addition to) the upstream headers? It has an ffitarget.h that conditionally includes the header for the various supported platforms and sets things appropriately. That way we don’t have to worry about keeping in sync; I’d worry about other differences in the configuration given that we’ve already had to replace one header and patch another.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opted to copy the platform-specific headers into the target config folder created by the configure script. That makes sure they’re consistent with the build, and lets the standard install phase handle copying them into place.

This ensures that the installed headers match those shipped with the
system libffi, which may enable or disable certain features depending on
the platform (such as the legacy closure API on x86_64-darwin).
echo '#define FFI_TRAMPOLINE_WHOLE_DYLIB 1' >> aarch64-apple-darwin/fficonfig.h
postConfigure = ''
# Use Apple’s configuration instead of the one generated by the `configure` script.
cp darwin/include/fficonfig_${stdenv.hostPlatform.darwinArch}.h ${stdenv.hostPlatform.config}/fficonfig.h
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

@reckenrode reckenrode Feb 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The missing include/ is intentional. The build system for libffi creates a folder for the target platform’s triple then generates <triple>/fficonfig.h, <triple>/include/ffi.h, and <triple>/include/ffitarget.h. I replace those in this derivation with Apple’s generated headers. Notably, fficonfig.h is not installed. It’s only used for building libffi. That’s why it’s not copied to <triple>/include.

Regarding tramp.h, it’s not a generated header. The build system doesn’t even copy it to <triple>. The one included with Apple’s headers is the same as the upstream one.

We could potentially run https://github.com/apple-oss-distributions/libffi/blob/83edf1120fbb1d9aace9b9eb87ac22198b1bc2e8/generate-darwin-source-and-headers.py ourselves if it’d make anything easier/cleaner…

Running generate-darwin-source-and-headers.py would create a circular dependency between libffi and Python. Either python3-minimal would have to be changed to build against libffiReal, the first build of libffi in the bootstrap would have to not run it, or the stdenv bootstrap would need to build another Python just for building darwin.libffi. I don’t think any of those would make the build easier or cleaner.

The cleanest thing to do would be to get the trampoline PR finally merged upstream and work out whatever configure flags are needed to duplicate Apple’s configuration. I’m not exactly familiar with aarch64 assembly, nor do I have a lot of bandwidth, so I’m probably not be the best person to try to do that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. This all seems reasonable to me then.

@reckenrode reckenrode merged commit 51b93f3 into NixOS:staging Feb 22, 2025
25 of 27 checks passed
@reckenrode reckenrode deleted the push-kqrzruxywypy branch February 22, 2025 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: darwin Running or building packages on Darwin 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants