GoStdlib includes absolute paths in the output

[AlessandroPatti]

What version of rules_go are you using?

0.48.0

What version of gazelle are you using?

N/A

What version of Bazel are you using?

7.2.1

Does this issue reproduce with the latest releases of all the above?

Yes

What operating system and processor architecture are you using?

Linux x86_64, but can repro on any platform

Any other potentially useful information about your toolchain?

Custom crosstool, using LLVM toolchain and custom sysroot. The crosstool setup find the sysroot and sets -I and -L to the correct relative paths

What did you do?

I am building a simple go binary, but the generated stdlib archives contain absolute paths. Looks like paths passed to the linker are expanded to absolute paths and stored in the object files. repro.zip contains a minimal repro:

$ unzip repro.zip
$ bazel build :example
$ strings $(find bazel-out/ -name cgo.a) | grep external/llvm

What did you expect to see?

Fully hermetic and reproducible builds

What did you see instead?

The full path in the output causes the output digest to change, reducing cache hits

[fmeum]

The situation as I understand it:

• go install runs the compilation in its own clean environment and thus doesn't permit us to pass in relative paths. Even worse: compiling with -x will lie to you about absolute paths as it rewrites them.
• All linker flags are persisted in cgo comments verbatim in _cgo_gotypes.go.
• Building the standard library doesn't actually produce any linker outputs, but the linker is run to produce objects passed in as cgo's -dynimport. Without proper linker flags, it may fail and then internal linking would no longer be possible.

The simplest fix I see would be to extend the existing filterbuildid tool to also remove all mentions of the execpath in _cgo_gotypes.go after the cgo command has completed.

[fmeum]

@AlessandroPatti Could you test the fix in #4005?

[AlessandroPatti]

strings $(find bazel-out/ -name cgo.a) | grep external/llvm

@fmeum Yes, it works on the repro! I'll try later on the original use case I had. It should also be applied to the stdliblist action?

[AlessandroPatti]

@fmeum I also have an alternative solution here, which instead just defers the expansion of the abs flags. Seems the abs paths are embedded only if the CGO_LDFLAGS env variable contains them. Did not get around to add tests but I could confirm it works

[fmeum]

I actually prefer your solution as the more principled one, so please send a PR if possible. A go_bazel_test that runs strings in a similar way as in your repro would be very welcome as well.

[AlessandroPatti]

@fmeum Opened #4009