New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Litarvan opened this Issue Dec 29, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@Litarvan

Litarvan commented Dec 29, 2017

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

This comment has been minimized.

Member

agnivade commented Dec 29, 2017

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

This comment has been minimized.

Litarvan commented Dec 29, 2017

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 odeke-em changed the title from go build with a .syso file on unix crashes the command to cmd/link: nicer error when trying to link an invalid .syso file built on another OS Dec 30, 2017

@odeke-em

This comment has been minimized.

Member

odeke-em commented Dec 30, 2017

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Dec 30, 2017

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."

@heschik

This comment has been minimized.

Contributor

heschik commented Jan 2, 2018

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

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Mar 28, 2018

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.

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Mar 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment