cmd/ld: can't statically link against freetype (mismatches non-TLS reference go.o)

[emidoots]

What steps will reproduce the problem?
1. extract zip with freetype.syso and main.go into $GOPATH/src/cgofreetype
2. $ go install cgofreetype
3. cmd/ld won't link the executable successfully using tip (but does with Go 1.2).

What is the expected output?
The program should successfully link (it does with Go 1.2 but not with tip).

What do you see instead?
$ go install cgofreetype

# cgofreetype
/usr/bin/ld: errno: TLS reference in /var/tmp/go-link-bBiYJF/000001.o mismatches non-TLS
reference in /var/tmp/go-link-bBiYJF/go.o
/var/tmp/go-link-bBiYJF/go.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
/home/stephen/go/pkg/tool/linux_amd64/6l: running gcc failed: unsuccessful exit status
0x100

Which compiler are you using (5g, 6g, 8g, gccgo)?
6l

Which operating system are you using?
$ uname -a
Linux stephen-N5110 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux

Which version are you using?  (run 'go version')
(tip)

$ uname -a
Linux stephen-N5110 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux

Please provide any additional information below.

$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Upon further inspection myself it seems that GCC's ld can't link because of the fact
that 000001.o (freetype.syso) contains errno which uses thread-local storage and go.o
which doesn't use thread-local storage ? I can't dig up more than this through Google.

I'm reporting this bug because the same program does link OK with Go 1.2, but I'm open
to ideas and workarounds regarding this issue if anyone can offer them.

I've attached a zip with all necessary files to reproduce the issue on linux/amd64.

Attachments:

1. cgofreetype.zip (3996625 bytes)

[gopherbot]

Comment 1 by capnm9:

Static linking of libm is IMHO generally a bad idea, I guess if you desist from doing
that, it will work.

[adg]

Comment 2:

Looks like a regression from 1.2.
capnm9: not helpful. Go binaries are statically linked, so it's perfectly reasonable to
want to statically link other objects into Go binaries.

Labels changed: added release-go1.3, repo-main.

Status changed to Accepted.

[emidoots]

Comment 3:

It is actually helpful, I did ask for workarounds anyone could provide. Dynamically
linking against libm does work for now, thanks!
It's still important to ensure there isn't any regression, of course.

[gopherbot]

Comment 4 by capnm9:

I don't think go binaries built with cgo can be completely statically linked, e.g. what
about libc and libpthread?

[minux]

Comment 5:

https://golang.org/cl/64340043/ should fix it.

Owner changed to @minux.

Status changed to Started.

[gopherbot]

Comment 6 by capnm9:

@minux: Yes, it does fix this.
The static libm has
$ nm --format sysv /usr/lib/x86_64-linux-gnu/libm.a|grep errno
errno        |           |   U  |          TLS|           |     |*UND*
which also triggers the bug.

[minux]

Comment 7:

This issue was closed by revision d4a9bbe.

Status changed to Fixed.