Skip to content

Fix cgo rpath computation for prebuilt dynamic libraries#2869

Merged
jayconrod merged 1 commit intobazel-contrib:masterfrom
TimothyGu:cgo-rpath
Jun 2, 2021
Merged

Fix cgo rpath computation for prebuilt dynamic libraries#2869
jayconrod merged 1 commit intobazel-contrib:masterfrom
TimothyGu:cgo-rpath

Conversation

@TimothyGu
Copy link
Copy Markdown
Contributor

What type of PR is this?

Bug fix

What does this PR do? Why is it needed?

Previously, we assumed that any dynamically linked library exists in execroot. This is the case if the library is NOT generated (e.g., prebuilt third-party SDKs). On the other hand, the library should always be symlinked in runfiles of the executable, so use that as the basis for rpath computation.

Which issues(s) does this PR fix?

Fixes #2867

Other notes for review

@jayconrod
Copy link
Copy Markdown
Collaborator

Sorry for the slow review on this. The fix looks good.

The one thing I'm nervous about is checking in binaries as part of the tests. We have no way of reviewing that code, and if it stops working, we have no way of fixing it.

I'm guessing we can't test this fix with binaries that are generated at build time, since they'll be in generated directories?

If that's the case, I'd be fine with marking the test with tags = ["manual"] and checking in a bash script that can be run first to generate the binaries, which won't be checked in. I can't really think of a better testing strategy.

cc @steeve also, who knows this code better than I do at this point.

@jayconrod jayconrod requested a review from steeve June 2, 2021 18:50
Previously, we assumed that any dynamically linked libraries are in
execroot. This may not be the case if the library is NOT generated.
However, the library should always be in runfiles.

Fixes #2867
@TimothyGu
Copy link
Copy Markdown
Contributor Author

@jayconrod Done. Created a generate_imported_dylib.sh script for the new tests.

Copy link
Copy Markdown
Collaborator

@jayconrod jayconrod left a comment

Choose a reason for hiding this comment

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

Looks good, thanks for fixing this.

I think the RBE failure was already corrected on master, so I'll go ahead and submit this.

@jayconrod jayconrod merged commit 5e6bd99 into bazel-contrib:master Jun 2, 2021
@TimothyGu TimothyGu deleted the cgo-rpath branch June 2, 2021 21:54
yushan26 pushed a commit to yushan26/rules_go that referenced this pull request Jun 16, 2025
… required (bazel-contrib#2869)

An upcoming change in Bazel makes the test toolchain required, which
means a compatible
exec platform amongst toolchains must be found
(bazelbuild/bazel@2780393).

Some analysis tests of `py_test` force the target platform to a specific
platform, but before this change didn't register a compatible exec
platform. This can be fixed by registering the target platform as an
exec platform. Since Python targets currently depend on a C++ toolchain
through Bazel's `launcher` and `launcher_maker` and the default
toolchain can't cross-compile to Linux, the host platform still needs to
be kept at highest priority to ensure that cross-compilation isn't
needed on macOS.

Work towards bazel-contrib#2850
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cgo rpath is incorrectly computed for non-generated cc_imported dynamic libraries

2 participants