Skip to content

[ci] minimal refactor to use cibuildwheel - #22886

Draft
siliataider wants to merge 17 commits into
root-project:test_macos_wheel_v2from
siliataider:silia/test_macos_wheel_v2_cibw
Draft

[ci] minimal refactor to use cibuildwheel#22886
siliataider wants to merge 17 commits into
root-project:test_macos_wheel_v2from
siliataider:silia/test_macos_wheel_v2_cibw

Conversation

@siliataider

@siliataider siliataider commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Replace manual build steps with cibuildwheel, mirroring the existing linux setup.

Builds wheels for cp310-cp314 on arm64.

@siliataider
siliataider requested a review from dpiparo as a code owner July 22, 2026 12:46
@github-actions

github-actions Bot commented Jul 22, 2026

Copy link
Copy Markdown

Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 1851a3d.

♻️ This comment has been updated with latest results.

@siliataider

Copy link
Copy Markdown
Contributor Author

FYI @dpiparo @vepadulano after the fixes #22917 and #22919 we can now build wheels with cibuildwheel and run our usual tests, they all pass except 2 ACLiC tutorials on the cp314 wheel. This appears to be the same issue reported in Homebrew/homebrew-core#272324

siliataider and others added 12 commits July 27, 2026 11:34
`TSystem::CompileMacro`, aka `ACLiC`, can generate a shared library from a ROOT macro. While doing so, it links the target library against all loaded libraries at time of calling.

When running from Python e.g. via `ProcessLine(".L macro.C+")`, the loaded libraries include those dynamically loaded by the Python interpreter.

When run on a MacOS system, these may also include so-called "private" Apple libraries. These libraries cannot be linked against by third-party code: the linker will fail with an error saying "product being built is not an allowed client of it".

One such situation has surfaced in a bug report to the homebrew distribution of ROOT Homebrew/homebrew-core#272324 related to the `libffi` library, but the issue is actually generic.

Unfortunately, Apple does not provide an authoritative list of "private" libraries and there is no direct way to ask a library whether linking against it will produce a linker error or not.

Aside from manually checking the list of allowed clients of each of the loaded libraries before linking, manually vetoing known "private" libraries seems the next-best thing. This commit proposes to remove the `libffi` library from the list of libraries `ACLiC` will link against when run on MacOS.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants