On Tuesday, March 9, 2021 at 7:04:17 AM UTC-5 axel.wa...@googlemail.com wrote:
> On Tue, Mar 9, 2021 at 12:39 PM tapi...@gmail.com <tapi...@gmail.com> > wrote: > >> But isn't assuming GOROOT exists almost equivalent to assuming "go" >> command exists? >> > > Maybe. As I said, it might have been possible to try `go env GOROOT` > instead or in addition to looking at $GOROOT. It might even be possible to > change that default now. There would likely still need to be *some* > fallback (as exec'ing `go` might fail). I honestly don't know. I do know > that the documentation currently does not say `go/build` is looking at `go > env`, though, but that it directly inspects the environment. > > In any case, note that you can get whatever behavior you like by > explicitly setting Context.GOROOT > <https://golang.org/pkg/go/build/#Context.GOROOT>. Given that it's easy > to overwrite the default behavior and given that `go/build` should, in > practice, be considered to be superseded by ` > golang.org/x/tools/go/packages` <http://golang.org/x/tools/go/packages>, > I don't personally feel much need to discuss the particulars. Maybe someone > else has more of a stake in this. > `golang.org/x/tools/go/packages` <http://golang.org/x/tools/go/packages> parse "unsafe" in an unexpected way, which is why I turned to "build.Import" instead. This workaround by setting Context.GOROOT <https://golang.org/pkg/go/build/#Context.GOROOT>. should work, I think. Thanks for the suggestion. > > >> >>> >>> 2. It exposes some personal privacy to make the last attempt work. By >>>> the document, it looks some personal privacy will be always record in the >>>> binary file, even if the last attempt is not adopted in the end. >>>> >>> >>> That is true. I think the practicalities of being able to run go tools >>> without configuration or environment variables outweigh this, though. For >>> example, if a user installs go and (say) goimports from their distribution >>> repository, we want the goimports binary to be able to find stdlib >>> packages, even if the user does not have GOROOT set. >>> Having the actual filesystem paths built in also simplifies debugging - >>> it means a debugger can find the files and show you source information. >>> While `go env GOROOT` might be able to replace the fallback for the former >>> use-case, it wouldn't be available to the debugger. >>> >>> Note that you can always remove any host-specific information by >>> building a go release in a generic path and use that to build go packages. >>> That is also what happens if you use a go release provided by your >>> distribution. So the downsides don't seem enormous, given that you can >>> always circumvent them with relatively little hassle. >>> >>> >>>> On Tuesday, March 9, 2021 at 2:53:19 AM UTC-5 axel.wa...@googlemail.com >>>> wrote: >>>> >>>>> https://golang.org/pkg/runtime/#GOROOT >>>>> >>>>> GOROOT returns the root of the Go tree. It uses the GOROOT environment >>>>>> variable, if set at process start, or else the root used during the Go >>>>>> build. >>>>> >>>>> >>>>> I don't understand how you expect a binary to find GOROOT otherwise, >>>>> if you don't set the environment variable. >>>>> >>>>> On Tue, Mar 9, 2021 at 6:38 AM tapi...@gmail.com <tapi...@gmail.com> >>>>> wrote: >>>>> >>>>>> I have two machines, their GOROOTs are different. >>>>>> I build a binary on one machine then transfer the binary to the other. >>>>>> It runs well on the machine the binary is produced on, but fails on >>>>>> the other. >>>>>> >>>>>> The code reporting the error is >>>>>> >>>>>> unsafePkg, err := build.Import("unsafe", "", build.FindOnly) >>>>>> if err != nil { >>>>>> log.Fatal(fmt.Errorf("build.Import: %w", err)) >>>>>> } >>>>>> >>>>>> The error is >>>>>> >>>>>> build.Import: go/build: go list unsafe: exit status 2 >>>>>> go: cannot find GOROOT directory: /home/myname/path/of/GOROOT >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "golang-nuts" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to golang-nuts...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/golang-nuts/c02407eb-2fec-4195-8ef3-46a33e233c66n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/golang-nuts/c02407eb-2fec-4195-8ef3-46a33e233c66n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golang-nuts...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/d5011895-955d-4400-ab65-122d68dd93d2n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/d5011895-955d-4400-ab65-122d68dd93d2n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/3baa8c24-5eb1-48bf-9fef-9c94ec765e29n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/3baa8c24-5eb1-48bf-9fef-9c94ec765e29n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d619118d-e8bb-4dff-894b-6ddf7abbc57en%40googlegroups.com.
