fix: handle builds with trimpath enabled

[gkampitakis]

Closing #118 🤞

[klaernie]

Golang accepts both -trimpath and --trimpath - and I know that due to old habits I tend to use -- interactively. Maybe it would be worth checking for both.

[gkampitakis]

ohhhh thanks for pointing this out 🙇 . Btw not sure but I can't find a "good" way to identify if build is trimpath when you run your tests like this

go test -trimpath ./...

if you have any ideas feel free to share them 😄

[klaernie]

Checking the $GOFLAGS is definitely more of an idea than I could up so far. My best idea was to go rooting around in the golang codebase in the search of the trimpath implementation and taking a look if it produces a side effect that one could measure. So far I figured out that the BuildTrimpath is relevant, but I haven't looked through the occurrences yet: https://github.com/search?q=repo%3Agolang/go%20BuildTrimpath&type=code

[klaernie]

One thing I did turn up: golang collects information about the build, and among the information recorded is if trimpath was enabled: https://github.com/golang/go/blob/e81f7155154c0f5d40363e84a8f24a5b559b5eed/src/cmd/go/internal/load/pkg.go#L2428

This recorded BuildSetting is then exposed to us with the runtime/debug package.

A trivial test looks like this:

package main

import (
        "runtime/debug"
        "fmt"
)

func main() {
        bi, ok := debug.ReadBuildInfo()
        if ! ok {
                fmt.Println("failed to fetch build info")
                return
        }
        fmt.Println(bi.Settings)
}

The result then is as following:

kandre@W-PF4PY6FH(pts/5) ~/go/src/test % go run main.go                                                                                               
[{-buildmode exe} {-compiler gc} {CGO_ENABLED 1} {CGO_CFLAGS } {CGO_CPPFLAGS } {CGO_CXXFLAGS } {CGO_LDFLAGS } {GOARCH amd64} {GOOS linux} {GOAMD64 v1}]

kandre@W-PF4PY6FH(pts/5) ~/go/src/test % GOFLAGS="" go run main.go
[{-buildmode exe} {-compiler gc} {CGO_ENABLED 1} {CGO_CFLAGS } {CGO_CPPFLAGS } {CGO_CXXFLAGS } {CGO_LDFLAGS } {GOARCH amd64} {GOOS linux} {GOAMD64 v1}]

kandre@W-PF4PY6FH(pts/5) ~/go/src/test % GOFLAGS="-trimpath" go run main.go
[{-buildmode exe} {-compiler gc} {-trimpath true} {CGO_ENABLED 1} {GOARCH amd64} {GOOS linux} {GOAMD64 v1}]

kandre@W-PF4PY6FH(pts/5) ~/go/src/test % go run -trimpath main.go
[{-buildmode exe} {-compiler gc} {-trimpath true} {CGO_ENABLED 1} {GOARCH amd64} {GOOS linux} {GOAMD64 v1}]

[gkampitakis]

I found this but unfortunately this information isn't always captured.

The previous commit on this pr was using the ReadBuildInfo, but when I tried running unit tests with trimpath it was not showing any details which is weird😞
7929c46 (#120)

This is what ReadBuildInfo doc states

// ReadBuildInfo returns the build information embedded
// in the running binary. The information is available only
// in binaries built with module support.

[klaernie]

Hm . I think if build info is present it would than still be the best way to use it, falling back to checking the env var.

I wonder what is causing that - does your go env point at anything specific? I'll have a try when I get some time near a proper PC.

[gkampitakis]

I have updated the function and on my testing

1. captures all cases, GOFLAGS, flag trimpath either from a main_test or package
2. don't see any regression on what already exists.

[klaernie]

Thanks for all the work you put in and for getting a solution so swiftly!

[gkampitakis]

Thank you for the reproduction and the clear explanation of the issue 🙇