-
-
Notifications
You must be signed in to change notification settings - Fork 702
go/tools/gopackagesdriver: Adding Cgo support #4338
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
linzhp
merged 3 commits into
bazel-contrib:master
from
r-hang:rhang/gopackagesdriver-cgo-support
May 19, 2025
Merged
go/tools/gopackagesdriver: Adding Cgo support #4338
linzhp
merged 3 commits into
bazel-contrib:master
from
r-hang:rhang/gopackagesdriver-cgo-support
May 19, 2025
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fmeum
reviewed
May 12, 2025
fmeum
approved these changes
May 12, 2025
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, looks great! Could you run buildifier to fix CI?
b6eb225
to
3536f78
Compare
linzhp
reviewed
May 13, 2025
d28387f
to
80a1f02
Compare
JamyDev
reviewed
May 16, 2025
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.
Also please add a test case for this functionality.
ff74244
to
46816cf
Compare
The gopackagesdriver today fails to load Go programs with cgo dependencies. These errors come from two sources: - First, Cgo source files are included in the CompiledGoFiles field of the packages driver response. - Second, the CompiledGoFiles field of the gopackages driver response does not contain the cgo processed Go sources necessary to compile programs. This change fixes these issues by: - Exposing the Cgo generated artifact directory in the GoArchive data. - Creating a Bazel rule to specially process and write *.pkg.json files that exclude Cgo source files and include Cgo generated code. Testing: With these changes, I was able to load one of the largest projects in my company's Bazel monorepo and use this data to generate a callgraph. With the sole package load error being caused by an external package with a go build taged file that renders the file inert for more recent versions of Go. ``` >> packages loaded: 991 -: sources missing for package @com_github_aws_aws_sdk_go//internal/context:context errors: 1 building ssa building callgraph with RTA callgraph nodes #: 209074 ``` ref bazel-contrib#4337
0278d30
to
86352a8
Compare
JamyDev
approved these changes
May 19, 2025
r-hang
added a commit
to r-hang/rules_go
that referenced
this pull request
Jun 4, 2025
When testing the bazel driver, we ran into an error that flaged that the argument list as too long. ``` ERROR: ...json failed: (Exit -1): pkgjson failed: error executing Action command (from target //...) bazel-out/k8-opt-exec-ST-a828a81199fe/bin/external/io_bazel_rules_go/go/tools/gopackagesdriver/pkgjson/reset_pkgjson/pkgjson --id @//src/... --pkg_path ... (remaining 15 arguments skipped) Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging Action failed to execute: java.io.IOException: Cannot run program "/home/user/.cache/bazel/_bazel_rhang/install/7e4ce7b0d69e79cb6bd84c7f9dfefe6b/process-wrapper" (in directory "/home/user/.cache/pkgdrv/0ddf1c72b811bee41d29991c732306ef72553747/sandbox/processwrapper-sandbox/29913/execroot/__main__"): error=7, Argument list too long ERROR: Build did NOT complete successfully ``` Digging into this issue, the cause is that the pkgjson command takes in all of the fields of package archive data as arguments. To work around this, we should preserve the original approach of writing a pkg json, before bazel-contrib#4338, which used Skylark builtins to write the package content directly to disk. The pkgjson command is updated to parse ths json file directly and write out a transformed pkg json with the cgo related corrections in order to avoid limits regarding argument size.
r-hang
added a commit
to r-hang/rules_go
that referenced
this pull request
Jun 6, 2025
When testing the bazel driver, we ran into an error that flaged that the argument list as too long. ``` ERROR: ...json failed: (Exit -1): pkgjson failed: error executing Action command (from target //...) bazel-out/k8-opt-exec-ST-a828a81199fe/bin/external/io_bazel_rules_go/go/tools/gopackagesdriver/pkgjson/reset_pkgjson/pkgjson --id @//src/... --pkg_path ... (remaining 15 arguments skipped) Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging Action failed to execute: java.io.IOException: Cannot run program "/home/user/.cache/bazel/_bazel_rhang/install/7e4ce7b0d69e79cb6bd84c7f9dfefe6b/process-wrapper" (in directory "/home/user/.cache/pkgdrv/0ddf1c72b811bee41d29991c732306ef72553747/sandbox/processwrapper-sandbox/29913/execroot/__main__"): error=7, Argument list too long ERROR: Build did NOT complete successfully ``` Digging into this issue, the cause is that the pkgjson command takes in all of the fields of package archive data as arguments. To work around this, we should preserve the original approach of writing a pkg json, before bazel-contrib#4338, which used Skylark builtins to write the package content directly to disk. The pkgjson command is updated to parse ths json file directly and write out a transformed pkg json with the cgo related corrections in order to avoid limits regarding argument size. Note: This diff also makes changes to undo a breaking change (i.e. changing the signature of the make_pkg_json function) that was made in bazel-contrib#4338. I revert changes to the functionalty of make_pkg_json and add a new replacement function make_pkg_json_with_archive.
r-hang
added a commit
to r-hang/rules_go
that referenced
this pull request
Jun 6, 2025
When testing the bazel driver, we ran into an error that flaged that the argument list as too long. ``` ERROR: ...json failed: (Exit -1): pkgjson failed: error executing Action command (from target //...) bazel-out/k8-opt-exec-ST-a828a81199fe/bin/external/io_bazel_rules_go/go/tools/gopackagesdriver/pkgjson/reset_pkgjson/pkgjson --id @//src/... --pkg_path ... (remaining 15 arguments skipped) Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging Action failed to execute: java.io.IOException: Cannot run program "/home/user/.cache/bazel/_bazel_rhang/install/7e4ce7b0d69e79cb6bd84c7f9dfefe6b/process-wrapper" (in directory "/home/user/.cache/pkgdrv/0ddf1c72b811bee41d29991c732306ef72553747/sandbox/processwrapper-sandbox/29913/execroot/__main__"): error=7, Argument list too long ERROR: Build did NOT complete successfully ``` Digging into this issue, the cause is that the pkgjson command takes in all of the fields of package archive data as arguments. To work around this, we should preserve the original approach of writing a pkg json, before bazel-contrib#4338, which used Skylark builtins to write the package content directly to disk. The pkgjson command is updated to parse ths json file directly and write out a transformed pkg json with the cgo related corrections in order to avoid limits regarding argument size. Note: This diff also makes changes to undo a breaking change (i.e. changing the signature of the make_pkg_json function) that was made in bazel-contrib#4338. I revert changes to the functionalty of make_pkg_json and add a new replacement function make_pkg_json_with_archive.
fmeum
pushed a commit
that referenced
this pull request
Jun 10, 2025
…#4371) When testing the bazel driver, we ran into an error that flaged that the argument list as too long. ``` ERROR: ...json failed: (Exit -1): pkgjson failed: error executing Action command (from target //...) bazel-out/k8-opt-exec-ST-a828a81199fe/bin/external/io_bazel_rules_go/go/tools/gopackagesdriver/pkgjson/reset_pkgjson/pkgjson --id @//src/... --pkg_path ... (remaining 15 arguments skipped) Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging Action failed to execute: java.io.IOException: Cannot run program "/home/user/.cache/bazel/_bazel_rhang/install/7e4ce7b0d69e79cb6bd84c7f9dfefe6b/process-wrapper" (in directory "/home/user/.cache/pkgdrv/0ddf1c72b811bee41d29991c732306ef72553747/sandbox/processwrapper-sandbox/29913/execroot/__main__"): error=7, Argument list too long ERROR: Build did NOT complete successfully ``` Digging into this issue, the cause is that the pkgjson command takes in all of the fields of package archive data as arguments. To work around this, we should preserve the original approach of writing a pkg json, before #4338, which used Skylark builtins to write the package content directly to disk. The pkgjson command is updated to parse ths json file directly and write out a transformed pkg json with the cgo related corrections in order to avoid limits regarding argument size. Note: This diff also makes changes to undo a breaking change (i.e. changing the signature of the make_pkg_json function) that was made in #4338. I revert changes to the functionalty of make_pkg_json and add a new replacement function make_pkg_json_with_archive.
linzhp
pushed a commit
that referenced
this pull request
Jun 10, 2025
…#4371) When testing the bazel driver, we ran into an error that flaged that the argument list as too long. ``` ERROR: ...json failed: (Exit -1): pkgjson failed: error executing Action command (from target //...) bazel-out/k8-opt-exec-ST-a828a81199fe/bin/external/io_bazel_rules_go/go/tools/gopackagesdriver/pkgjson/reset_pkgjson/pkgjson --id @//src/... --pkg_path ... (remaining 15 arguments skipped) Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging Action failed to execute: java.io.IOException: Cannot run program "/home/user/.cache/bazel/_bazel_rhang/install/7e4ce7b0d69e79cb6bd84c7f9dfefe6b/process-wrapper" (in directory "/home/user/.cache/pkgdrv/0ddf1c72b811bee41d29991c732306ef72553747/sandbox/processwrapper-sandbox/29913/execroot/__main__"): error=7, Argument list too long ERROR: Build did NOT complete successfully ``` Digging into this issue, the cause is that the pkgjson command takes in all of the fields of package archive data as arguments. To work around this, we should preserve the original approach of writing a pkg json, before #4338, which used Skylark builtins to write the package content directly to disk. The pkgjson command is updated to parse ths json file directly and write out a transformed pkg json with the cgo related corrections in order to avoid limits regarding argument size. Note: This diff also makes changes to undo a breaking change (i.e. changing the signature of the make_pkg_json function) that was made in #4338. I revert changes to the functionalty of make_pkg_json and add a new replacement function make_pkg_json_with_archive.
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
go/tools/gopackagesdriver: Filter cgo sources and add cgo processed files
The gopackagesdriver today fails to load Go programs
with cgo dependencies.
These errors come from two sources:
CompiledGoFiles response.
contain cgo processed Go sources necessary to compile the program.
This change addresses both error points by
checking if the files import "C".
knowledge of how rules_go compiles cgo files.
I am not sure if there is a better solution to leaking build system
details to the gopackagesdriver as even 'go list' leaks where
the go build cache stores cgo processed files. Though in the case of 'go list'
the conventions for cgo processed files are a bit different, they don't
seem to have a file extension.
For example,
This PR resolves #4337 additional
details are provided in the issue.