On 2/14/2014 19:44, Justin Sherrill wrote: > we have two 'builders' going, for 32 and 64 bit DragonFly, and the > output on every automatic build caused by a commit is here: > > http://build.golang.org/ > > The current error for DragonFly is: > > # cmd/go > /usr/libexec/binutils224/elf/ld.bfd: errno: TLS reference in > /var/tmp/go-link-cR28Gg/000000.o mismatches non-TLS reference in > /var/tmp/go-link-cR28Gg/go.o > /var/tmp/go-link-cR28Gg/go.o: error adding symbols: Bad value > /tmp/gobuilder/dragonfly-amd64-5cfa01069440/go/pkg/tool/dragonfly_amd64/6l: > running gcc failed: unsuccessful exit status 0x100 > Build complete, duration 20.525676284s. Result: error: exit status 2 > > My hunch is that it's caused by our version of gcc being newer than > every other BSD, and so TLS is being handled differently enough that > it's causing this problem. That's a hunch, though, and not based on > knowing what I am doing. > > It happened here: > > https://code.google.com/p/go/source/detail?r=7d72bbcb979dfc9f15df05908149339401f8f42a > > I haven't been able to figure it out, but if someone with more > experience can glance at it and solve this I-hope-very-simple problem, > that would be wonderful. Longer term maintenance is a thing, too, but > right now this is the immediate hurdle.
That looks like a old-style errno error. I see signatures like that when "extern int errno;" appears instead of "#include <errno.h>". I haven't looked at the code but I'd bet it's falling down to a platform where errno is an extern. I'd prefer somebody else verify that, I've got a bunch of stuff to do right now. John
