Avoid linking against private Apple libraries with ACLiC - #22963
Conversation
|
Thanks a lot @vepadulano ! This patch is necessary for the macOS experimental wheels to pass all the tests |
e0e49d0 to
87a6602
Compare
|
The Mac runners of our CI do not present the same error as the linked reproducer. After a debugging session with @siliataider I realize it's because one fundamental ingredient to reproduce the issue is the Python version: the OP's environment as well as my machine have Python 3.14 . For reference, I paste here the result of the added ctest on my machine: Unfortunately, there is no easy way to run on our self-hosted Mac runners with a different Python version than the system one, so we may have to accept this PR based on my local results alone. Or think about a way to run a ROOT installation from a PR build artifacts on a different MacOS runner with a different Python version. |
Test Results 23 files 23 suites 3d 17h 14m 50s ⏱️ Results for commit 0c5b114. ♻️ This comment has been updated with latest results. |
|
This is the compiler invocation issued by ACLiC on the Mac26 CI runner https://github.com/root-project/root/actions/runs/30551851395/job/90902330650?pr=22963 (WARNING: obtained by setting Note the absence of |
`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.
87a6602 to
0c5b114
Compare
siliataider
left a comment
There was a problem hiding this comment.
I can reproduce the failure on my machine, and I have tested the patch from your branch @vepadulano , looks like it works!
|
I patched the PR #22886 of the experimental macOS wheels with your fix, this PR builds and tests the wheels on 2 different github macOS runners, and tests them using 5 different Python versions including |
|
As a further confirmation, the CI runs on wheels produced and tested on Mac26 runners with Python 3.14 are now successfull, see https://github.com/root-project/root/actions/runs/30621397526?pr=22886 . |
Fixes Homebrew/homebrew-core#272324