-
-
Notifications
You must be signed in to change notification settings - Fork 592
fix: Fix up search path of bootstrapped Python toolchain dylib #2089
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
476bd7d
to
078f566
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, could you please add a line in CHANGELOG
to say that this behaviour was fixed?
@rickeylev, could you PTAL and see if something is missing from your point of view? IMHO this is good to merge as is, because there was a test and things started working better than they used to before the change.
Previously, `//tests/cc/current_py_cc_libs::python_libs_linking_test` failed on macOS because the bootstrapped toolchain's dylib had an incorrect LC_ID_DYLIB field set, pointing to a local directory on the Python standalone build host machine. To fix, add a small conditional to the Python repository rule patching the LC_ID_DYLIB field of the bootstrapped Python's dylib with its fully qualified file system path. Patching is carried out with macOS's own `install_name_tool`, which is part of the standard macOS dynamic linking toolchain. Since this needs macOS to be the host platform, restrict this change to macOS host systems only by checking the host OS name. Qualifies the mentioned test as executable on Mac, now only Windows linker errors are left to fix.
078f566
to
48d30c5
Compare
I added a note to the changelog in the latest revision. Thanks for the speedy review! |
Any more issues on your end @aignas @rickeylev ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Doesn't setting this to an absolute path mean you get a non-hermetic build if you link this dylib? |
Previously,
//tests/cc/current_py_cc_libs::python_libs_linking_test
failed on macOS because the bootstrapped toolchain's dylib had an incorrect LC_ID_DYLIB field set, pointing to a local directory on the Python standalone build host machine.To fix, add a small conditional to the Python repository rule patching the LC_ID_DYLIB field of the bootstrapped Python's dylib with its fully qualified file system path. Patching is carried out with macOS's own
install_name_tool
, which is part of the standard macOS dynamic linking toolchain.Qualifies the mentioned test as executable on Mac, now only Windows linker errors are left to fix.