Assembly files not classified correctly, based on cgo mode #2006
Comments
|
This happens for datadog/zstd - I hit this when using gazelle to generate deps for ethereum-go : this is the workaround in that case: https://github.com/aspect-build/rules_sol/pull/8/files#diff-1f2c31b701f066691b4a4024644f86e092ab731eb81cc5d6282017fe485082ae |
|
If we can't fix the issue in Gazelle, we could add the affected Go repos to the BCR with the fixing patches applied, as we did for circl. |
This was referenced Aug 10, 2023
fmeum
pushed a commit
that referenced
this issue
Aug 12, 2023
…3652) The native "go build" tool compiles assembly in a Cgo package with the C compiler, and compiles assembly in a pure Go package with the Go assembler. The build_constraints test previously mixed Go assembler files with Cgo files. This caused the native go test to fail with: package using cgo has Go assembly file asm_linux_amd64.s Splitting this into two separate packages fixes this. This problem was reported in: #2006 This will fix failing tests in my attempt to fix that issue: #3648
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of rules_go are you using?
0.18.1
What version of Bazel are you using?
0.23.2
Does this issue reproduce with the latest releases of all the above?
Yes
What did you do?
//tests/legacy/build_constraints:go_default_testis incorrect. It includes Go assembly files in a package with cgo.What did you expect to see?
Go assembly sources should be rejected with a message like
package using cgo has Go assembly file asm_linux.s. Both .s and .S files should be included in the build and should be assembled with the C compiler. This should only happen for packages withcgo = Truewhen cgo is enabled.What did you see instead?
Go assembly sources are assembled with the Go assembler. .S files should not be included in the build unless
cgo = Trueand cgo is enabled.The text was updated successfully, but these errors were encountered: