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:

Well, we don't have two builders going anymore.  Justin, apparently you
manually started these builders in screen?  They need to be started via
RC.init script on server startup.  I rebuilt world/kernel on pkgbox64
and rebooted recently (something that happens rather frequently) and
probably not coincidentally, the 64-bit go builder has been MIA for the
last many commits.  Anyway the builder has to started automatically, it
can't be a manual thing.


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

To repeat what I said in another thread, it's not a GCC thing, it's an
error definition thing.  I normally see this when "extern int errno;" is
defined instead of "#include <errno.h>".  That being said...

> 
> It happened here:
> 
> https://code.google.com/p/go/source/detail?r=7d72bbcb979dfc9f15df05908149339401f8f42a

... I don't immediately see anything in those diffs related to errno.
Are you sure this is the commit?  The strange thing is the error seems
to be coming from running Go, not building it (where I normally see this
error)


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

Unfortunately we've not had a single person even inquire about picking
up this task.  If we lose Go support, nobody can say a *damn thing*
about it.

John