Fwd: [golang-dev] Re: dragonfly support

[John Marino]

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