Skip to content

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

Merged
merged 1 commit into from
Aug 14, 2024

Conversation

nicholasjng
Copy link
Contributor

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.

@nicholasjng nicholasjng force-pushed the mac-dyldpath-fixup branch 2 times, most recently from 476bd7d to 078f566 Compare July 26, 2024 05:59
Copy link
Collaborator

@aignas aignas left a 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.
@nicholasjng
Copy link
Contributor Author

I added a note to the changelog in the latest revision. Thanks for the speedy review!

@nicholasjng nicholasjng requested a review from aignas August 9, 2024 19:38
@nicholasjng
Copy link
Contributor Author

Any more issues on your end @aignas @rickeylev ?

Copy link
Collaborator

@aignas aignas left a comment

Choose a reason for hiding this comment

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

Thanks!

@aignas aignas added this pull request to the merge queue Aug 14, 2024
Merged via the queue into bazel-contrib:main with commit 4f97f1a Aug 14, 2024
4 checks passed
@keith
Copy link
Member

keith commented Sep 26, 2024

Doesn't setting this to an absolute path mean you get a non-hermetic build if you link this dylib?

@keith
Copy link
Member

keith commented Sep 26, 2024

#2256

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.

3 participants