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
I'm not cross compiling the tool chain. I'm cross compiling a binary(Mage) that
just calls os/exec with "go", "build" and passes through os.Environ
I'll see if I can repro with a minimal example tonight.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts
On Sun, Oct 15, 2017 at 5:22 AM, Nate Finch wrote:
> https://github.com/magefile/mage/issues/69
>
> Mage calls go build via os/exec, explicitly passing through os.Environ to
> the subprocess.
>
> Somehow the cross compiled binary from my osx laptop is referencing the
> goroot from my laptop whe
I cross compiled using go 1.9 if it matters.
--
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 ht
https://github.com/magefile/mage/issues/69
Mage calls go build via os/exec, explicitly passing through os.Environ to the
subprocess.
Somehow the cross compiled binary from my osx laptop is referencing the goroot
from my laptop when it tries to run go build on a Linux machine.
1. How is this
