cmd/link: nicer error when trying to link an invalid .syso file built on another OS

[Litarvan]

What version of Go are you using (go version)?

go version go1.9.2 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/litarvan/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build281376345=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

I did, on linux, go build . on a project firstly created on Windows, containing a main.go file but also a resource.syso file generated with winres, that contains my icon file for the windows executable. The build was from linux this time, targeting linux, so i didn't pay attention to the .syso file.

What did you expect to see?

A working build

What did you see instead?

go build . dropped this error :

/usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/tmp/go-link-918954239/000000.o: file not recognized: File format not recognized
collect2: error: ld returned exit status 1

It took me like 1 hour to think that go build was trying to include the .syso file even when i was on linux, and was crashing the build because of this, i didn't really pay attention to the command as it was issued by a script.

go build should ignore .syso file on systems other than windows, or (i don't know if .syso is a windows-only extension) display a more readable error

[agnivade]

Have you tried using build tags ? https://golang.org/pkg/go/build/. They are ideal to deal with your situation.

I don't think Go should accept/ignore any files by itself. This is an application specific behavior and should be handled by the programmer. Build tags are the way to go.

[Litarvan]

Even if it is a specifid behavior, the point of "go build ." is to ignore every files except the .go files, and some like .syso. Anyway, i was just saying that a clearer error would be nice ?

[odeke-em]

/cc @ianlancetaylor

[ianlancetaylor]

All the Go toolchain does with a .syso file is turn it over to the external linker. It is the external linker that is producing that error message. I'm not clear on what the Go tools can do to get a better error, but I'm open for suggestions. I suppose the Go tool could say something like "by the way, when the linker failed just then, we were passing it a .syso file."

[heschi]

The Go linker could give the file a more helpful name than 000000.o, maybe 000000_resource_syso.o or something like that?

[ianlancetaylor]

At the point where the linker is invoked, the .syso file has been stuffed into an archive, and the name has potentially been truncated. I don't think we should print a truncated name, and I don't feel like going to the effort of preserving the original name.

[eljobe]

I have been looking at alternative uses of .syso files. They are a good mechanism for generically linking against library archives whether or not they contain Windows resources. So, I'd actually recommend closing this issue as working as intended. With the ability to have names like some_linux_arm64.syso and some_windows.syso and the linker and archive tool doing the right thing, I think the request here doesn't really need more work from the go team.