cmd/go: unbootstrapped cross compiler doesn't emit helpful error anymore

[dominikh]

In Go 1.4 and before, go build would say $GOOS/$GOARCH must be bootstrapped using make.bash because it would detect missing zasm files.

In tip, we have zgoos files, which are created by go generate, so they always exist for all GOOS/GOARCH combinations. cmd/dist, however, is still responsible for copying textflag.h into the per-GOOS/GOARCH pkg/ directories. Building Go for a single platform and trying to go build for a different platform now won't result in a helpful error, but instead the assembler won't be able to find textflag.h:

Expected output:

dominikh-pc /tmp $ GOOS=darwin go build
go build runtime: darwin/amd64 must be bootstrapped using make.bash

Actual output:

dominikh-pc /tmp $ GOOS=darwin go build
# runtime
/home/dominikh/go/src/runtime/asm.s:6 6a: No such file or directory: textflag.h

Version:

go version devel +3fa5d3a Thu Dec 11 15:23:18 2014 +0000 linux/amd64

This only affects tip, not Go 1.4.

[minux]

Either we teach cmd/go to also copy that file or treat the missing of that
file as an indication
of not bootstrapped.

I'd prefer the former, because cmd/dist no longer generates any files for
the runtime package.

[bradfitz]

I would like to see go build just work for any OS/ARCH pair in Go 1.5, without the user having to do anything. (And regardless of whether their $GOROOT is in $HOME/go or unwritable /usr/, /var/, etc)

[minux]

On Thu, Dec 11, 2014 at 5:06 PM, Brad Fitzpatrick [email protected]
wrote:

I would like to see go build just work for any OS/ARCH pair in Go 1.5,
without the user having to do anything. (And regardless of whether their
$GOROOT is in $HOME/go or unwritable /usr/, /var/, etc)

Possible if the user also supplies CC, CXX and other necessary flags
necessary for cross compilation.
Yeah, that will be ideal (though if the GOOS/GOARCH combination has been
installed, each time go build
will build everything from scratch; not that bad if we fix #8893)

[minux]

could we stop copying textflag.h to $GOROOT/pkg/$GOOS_$GOARCH, and instead put it
in a separate directory in $GOROOT (e.g. $GOROOT/src/internal/runtime), and always
pass -I $GOROOT/src/internal/runtime to the assemblers?

In this way, even if the user can't write to $GOROOT/pkg, they can still use go build to
cross compile for another architecture, and we also save one file copying operation.

[davecheney]

I think it is reasonable if you (the developer) are going to set up a cross
compiling installation you start with the source release. Given you have to
compile the additional architectures on your development machine it doesn't
seem like an undue request to compile the first architecture as well.

On Wed, Dec 31, 2014 at 12:21 PM, Minux Ma [email protected] wrote:

could we stop copying textflag.h to $GOROOT/pkg/$GOOS_$GOARCH, and instead
put it
in a separate directory in $GOROOT (e.g. $GOROOT/src/internal/runtime),
and always
pass -I $GOROOT/src/internal/runtime to the assemblers?

In this way, even if the user can't write to $GOROOT/pkg, they can still
use go build to
cross compile for another architecture, and we also save one file copying
operation.

—
Reply to this email directly or view it on GitHub
#9272 (comment).

[minux]

On Tue, Dec 30, 2014 at 9:35 PM, Dave Cheney [email protected]
wrote:

I think it is reasonable if you (the developer) are going to set up a
cross
compiling installation you start with the source release. Given you have
to
compile the additional architectures on your development machine it
doesn't
seem like an undue request to compile the first architecture as well.

What I'm concerned about is not compiling the toolchain programs, but you
need to run make.bash --no-clean for each platform (OS/arch pair) that you
want to cross compile to.

Ideally, once you have the toolchain programs, building a one-shot program
for a new platform should be as easy as:
GOOS=goos GOARCH=goarch go build import/path

Even if you're using binary distributions, you should still be able to cross
compile for the same architecture but different OSes easily (without
modifying
$GOROOT/pkg), that's why I propose that we move the only remaining required
headers files into internal/runtime so that they don't need to be in
$GOROOT/pkg/$GOOS_$GOARCH.

[davecheney]

Fair enough, thanks for clarifying. If it really is as simple as ensuring
the textflag.h files are present (I take no position on a new internal
package) then go build will be able to create everything from the runtime
upwards as required, then go for it.

On Fri, Jan 2, 2015 at 9:41 AM, Minux Ma [email protected] wrote:

On Tue, Dec 30, 2014 at 9:35 PM, Dave Cheney [email protected]
wrote:

I think it is reasonable if you (the developer) are going to set up a
cross
compiling installation you start with the source release. Given you have
to
compile the additional architectures on your development machine it
doesn't
seem like an undue request to compile the first architecture as well.

What I'm concerned about is not compiling the toolchain programs, but you
need to run make.bash --no-clean for each platform (OS/arch pair) that you
want to cross compile to.

Ideally, once you have the toolchain programs, building a one-shot program
for a new platform should be as easy as:
GOOS=goos GOARCH=goarch go build import/path

Even if you're using binary distributions, you should still be able to
cross
compile for the same architecture but different OSes easily (without
modifying
$GOROOT/pkg), that's why I propose that we move the only remaining required
headers files into internal/runtime so that they don't need to be in
$GOROOT/pkg/$GOOS_$GOARCH.

—
Reply to this email directly or view it on GitHub
#9272 (comment).

[minux]

We don't need to create a new internal package, I just can't think
of an appropriate directory to put the textflag.h. Ideally we will want
a new directory, so that we can limit the header files that could be
included.

I've also considered always including those macros in cmd/[5689]a
so that no #include is needed. But that means we can't easily modify
textflag.h without also updating the assembler source code. (although
i imagine we can use go generate for that, esp. after we have cmd/asm
in Go.)

[dominikh]

Does https://go-review.googlesource.com/#/c/6471/ address this?

[minux]

Yes.