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

cmd/go: export module information for binaries programmatically #26404

Open
bcmills opened this Issue Jul 16, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@bcmills
Member

bcmills commented Jul 16, 2018

https://research.swtch.com/vgo-repro says:

When we do integrate versions into the main Go toolchain, we will add APIs to access this information from inside a running binary, just like runtime.Version provides access to the more limited Go version information.

I didn't see an issue filed to track that, so I'm filing it now.

@bcmills bcmills added this to the Go1.12 milestone Jul 16, 2018

@mvdan

This comment has been minimized.

Member

mvdan commented Jul 16, 2018

This would be great - I think it has been one of the biggest reasons why some projects have been using makefiles and custom build scripts.

@gopherbot

This comment has been minimized.

gopherbot commented Oct 23, 2018

Change https://golang.org/cl/143977 mentions this issue: cmd/go/internal/modload: fix use of //go:linkname

gopherbot pushed a commit that referenced this issue Oct 23, 2018

cmd/go/internal/modload: fix use of //go:linkname
I can't find the exact rule about space before compiler directive
openings from
https://golang.org/cmd/compile/#hdr-Compiler_Directives
but it seems like the compiler doesn't recognize it
as a compiler directive if it is preceded by space.
Removing the space made the //go:linkname in the __gomod__.go file
working as intended.

Manually tested.

Update #26404

Change-Id: I589f7203a628b2fa6238d82878029e0f098091b6
Reviewed-on: https://go-review.googlesource.com/c/143977
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@hyangah

This comment has been minimized.

Contributor

hyangah commented Oct 23, 2018

The cl/143977 allowed us to retrieve the module information embedded during build. The API will be in the runtime/debug package.

BTW, using this info for version stamping of a binary instead of Makefiles and custom build scripts that utilize '-X' flag, works only when 1) the binary is built in the module enabled mode and 2) the binary is built through the module cache.

If the binary is built with the traditional GOPATH way, the info will not exist. If module is enabled but the binary is built out of checked in or cloned source repository, all dependency version info will be encoded but the main module's version info will remain undetermined (for the reason explained in the issue 28083).

@gopherbot

This comment has been minimized.

gopherbot commented Oct 23, 2018

Change https://golang.org/cl/144220 mentions this issue: runtime/debug: add API to read module info in binary

gopherbot pushed a commit that referenced this issue Nov 13, 2018

runtime/debug: add API to read module info in binary
When module is enabled, the go tool embeds build information
related to the module in the binary including the dependencies
and the replace information (See
src/cmd/go/internal/modload.PackageBuildInfo).

The newly introduced ReadBuildInfo reads the information and
makes it accessible programmatically.

Update #26404

Change-Id: Ide37022d609b4a8fb6b5ce02afabb73f04fbb532
Reviewed-on: https://go-review.googlesource.com/c/144220
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
@bcmills

This comment has been minimized.

Member

bcmills commented Nov 15, 2018

@hyangah, I notice that https://golang.org/cl/144220 is merged. Is there anything more to do for this issue, or should we close it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment