Fwd: [golang-dev] Re: dragonfly support

Justin Sherrill justin at shiningsilence.com
Fri Feb 14 10:44:50 PST 2014


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.

(There's an older issue that may be masked by this:
http://build.golang.org/log/aafac18b6c7417b08ef45ef2405f027d035528e0)


On Fri, Feb 14, 2014 at 6:37 AM, John Marino <dragonflybsd at marino.st> wrote:
> On 2/13/2014 19:35, Brad Fitzpatrick wrote:
>> Dragonfly Go users,
>>
>> Two weeks until freeze.  The builder is currently broken.  Anybody
>> interested in fixing it or maintaining the port?
>>
>
> Hey guys,
> Brad is asking a valid question.
> I've heard several pro-Go guys talk on IRC.
> This is not a language that I'm working with and frankly I'm more than
> swamped with maintaining the other 21,000 dports mostly by myself.
> Somebody that's been making noise about Go should step up here.  They
> don't have to solve problems by themselves, but they are expected to
> monitor for failures and bring those forward if the fix isn't simple.
>
> At the very least somebody needs to step up as a one-time deal prior to
> their freeze!
>
> John



More information about the Users mailing list