There's no explicit use or inspection of GOROOT at all (aside from what I just added to add GOROOT to the execution, which since it didn't help, I may strip out). The code has no external dependencies aside from the stdlib and stuff in its own repo. Obviously there's something which is influencing the behavior, but it's very weird to me that any difference in how mage is compiled should affect how a command it runs in a subprocess executes (aside from environment variables).
I'll continue trying to pare down what mage does to see if I can isolate what code is making the difference between the failing program and the succeeding one On Monday, October 16, 2017 at 12:22:00 PM UTC-4, Daniel Skinner wrote: > > As mentioned in last paragraph here: https://golang.org/pkg/runtime/ > > GOARCH, GOOS, and GOROOT are recorded at compile time and made available > by constants or functions in this package, but they do not influence the > execution of the run-time system. > > I'd first be inclined to think Mage source has done something to cause the > GOROOT constant to influence run-time execution. > > On Mon, Oct 16, 2017 at 11:27 AM Nate Finch <nate....@gmail.com > <javascript:>> wrote: > >> well now, that's weird. I just tried this in a minimal use case, >> compiled a linux command on my mac and ran it on my ubuntu box that just >> did the below... and it worked. Now I'm wondering what the difference is. >> >> >> On Monday, October 16, 2017 at 10:55:02 AM UTC-4, Nate Finch wrote: >>> >>> Nope, I'm wrong. It was an invalid test. It's still failing. >>> >>> I'm going to raise this as an issue on the go tool. >>> >>> IMO, this should work, and does not: >>> >>> c := exec.Command("go", "build", "main.go") >>> c.Env = append(os.Environ(), "GOROOT="+goroot) >>> err := c.Run() >>> >>> It should probably even work without setting GOROOT explicitly, but it >>> definitely should if I do (presuming GOROOT is correct, of course) >>> >>> >>> >>> On Monday, October 16, 2017 at 12:07:06 AM UTC-4, Nate Finch wrote: >>>> >>>> Reporting back: this worked perfectly. >>>> >>>> On Sunday, October 15, 2017 at 7:43:47 PM UTC-4, Dave Cheney wrote: >>>>> >>>>> Thank should work. >>>>> >>>>> On Monday, 16 October 2017 10:30:45 UTC+11, Nate Finch wrote: >>>>>> >>>>>> hmm... I really don't want people to have to build Mage, since mage >>>>>> is a build tool. Would it be horrible to just run go env GOROOT and >>>>>> use that to set GOROOT in the environs for the command that runs go >>>>>> build? >>>>>> >>>>>> >>>>>> On Sunday, October 15, 2017 at 5:36:43 PM UTC-4, Dave Cheney wrote: >>>>>>> >>>>>>> My guess is that GOROOT is not set in the target environment so the >>>>>>> value eventually collapses back on the GOROOT compiled into mage from >>>>>>> the >>>>>>> value compiled into the toolchain that built mage. >>>>>>> >>>>>>> gb has the same problem, I didn’t want to encourage people to set >>>>>>> GOROOT, but if they don’t, there is no way to find the right tool >>>>>>> chain. >>>>>>> >>>>>>> I gave up and stoped distributing binary images, which 1/2 solved >>>>>>> the problem. >>>>>> >>>>>> -- >> 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 <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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. For more options, visit https://groups.google.com/d/optout.
