You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The sections are in a different order using gold but things look OK. In particular the sections themselves seem to have exactly the same bytes in either build.
But while normally go test -run NoteReading cmd/go passes, if I change it to use gold, it fails:
This makes Go using gold do spurious rebuilds of binaries, because they appear out of date but are not.
I discovered this by compiling gccgo from source, which installed a new gcc into /usr/local/bin, and I'd (apparently mistakenly) configured with --with-ld=/usr/bin/gold. I will rebuild without that, but we should probably understand what is going on here.
I remember that in the past we've had problems with Ubuntu shipping ancient buggy versions of gold. I wondered if that might be the case here, but objdump and readelf are happy with the binary, so the go command probably should be made to be happy too.
The text was updated successfully, but these errors were encountered:
The bug is that the Go linker is using the wrong alignment for the SHT_NOTE section. The difference is that gold accumulates the SHT_NOTE sections into a single PT_NOTE segment, where the alignment makes the note impossible to find reliably. The GNU linker generates multiple PT_NOTE segments.
cmd/go is apparently unable to read the Go build ID from ELF binaries created by /usr/bin/gold on Ubuntu 17.04, which is:
If I build with external linking with and without gold, I get different binaries, both of which seem to have a valid .note.go.buildid section:
The sections are in a different order using gold but things look OK. In particular the sections themselves seem to have exactly the same bytes in either build.
But while normally
go test -run NoteReading cmd/go
passes, if I change it to use gold, it fails:This makes Go using gold do spurious rebuilds of binaries, because they appear out of date but are not.
I discovered this by compiling gccgo from source, which installed a new gcc into /usr/local/bin, and I'd (apparently mistakenly) configured with
--with-ld=/usr/bin/gold
. I will rebuild without that, but we should probably understand what is going on here.I remember that in the past we've had problems with Ubuntu shipping ancient buggy versions of gold. I wondered if that might be the case here, but objdump and readelf are happy with the binary, so the go command probably should be made to be happy too.
The text was updated successfully, but these errors were encountered: