Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/cgo: build fails on OS X 10.6 #5130

Closed
ianlancetaylor opened this issue Mar 26, 2013 · 7 comments

Comments

@ianlancetaylor
Copy link
Contributor

commented Mar 26, 2013

According to http://build.golang.org/ , the build is failing on amd64 OS X 10.6.  This
should be fixed.

E.g., from http://build.golang.org/log/1ab73cb109a61d71b1409c4b79cd6a257ef9e997 :

# ../misc/cgo/test
# testmain
ld: in /Volumes/ramdisk/tmp/go-link-Ajf7al/go.o, in section __TEXT,__text reloc 0: local
relocation for address 0x00002020 in section __text does not target section __bss
collect2: ld returned 1 exit status
syscall.errors:
/private/tmp/gobuilder/darwin-amd64-3792a253f8a4/go/pkg/tool/darwin_amd64/6l: running
gcc failed: unsuccessful exit status 0x100
FAIL    _/private/tmp/gobuilder/darwin-amd64-3792a253f8a4/go/misc/cgo/test [build failed]
PASS
ok      _/private/tmp/gobuilder/darwin-amd64-3792a253f8a4/go/misc/cgo/test  1.123s
# testmain
ld: in /Volumes/ramdisk/tmp/go-link-lEVTZa/go.o, in section __TEXT,__text reloc 0: local
relocation for address 0x00002020 in section __text does not target section __bss
collect2: ld returned 1 exit status
syscall.errors:
/private/tmp/gobuilder/darwin-amd64-3792a253f8a4/go/pkg/tool/darwin_amd64/6l: running
gcc failed: unsuccessful exit status 0x100
FAIL    _/private/tmp/gobuilder/darwin-amd64-3792a253f8a4/go/misc/cgo/test [build failed]
Build complete, duration 2m36.823044317s. Result: error: exit status 2
@davecheney

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2013

Comment 1:

Thanks for raising this issue. This machine belongs to adg.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2013

Comment 2:

My current diagnosis is that the Darwin linker on 10.6 has a bug.  It does not correctly
handle a X86_64_RELOC_UNSIGNED relocation with a size other than 64 bits.  You can see
the bug at line 4592 of
http://opensource.apple.com/source/ld64/ld64-95.2.12/src/ld/MachOReaderRelocatable.hpp .
 It does an unconditional 64-bit load regardless of the relocation length.  It then
checks to see that the loaded address is within the target section.
6l is using 32 bit addresses to load variable addresses.  This is unusual on a 64-bit
system but it works fine provided the linker always puts the code in the low order 32
bits of the address space.  Unfortunately this triggers the bug in the Darwin linker.
In 10.7 the linker appears to have been completely rewritten, and it no longer has this
bug.
One possible fix would be to change 6l to convert MOVQ from an absolute address to use
RIP-relative addressing instead.  That would continue using a 32-bit address, but would
produce a relocation that the Darwin 10.6 linker can understand.  I don't know how
complex that would be.  I also don't know if there are other cases that would have to be
addressed.
@eliasnaur

This comment has been minimized.

Copy link
Contributor

commented Mar 28, 2013

Comment 3:

Note that I've already added the necessary PIC changes to 6l, guarded by the -shared
flag. I suppose darwin (10.6) could re-use the PIC mode, but since RIP-relative
addressing excludes other useful addressing modes the resulting code size will grow,
which is probably not an acceptable tradeoff.
@eliasnaur

This comment has been minimized.

Copy link
Contributor

commented Mar 28, 2013

Comment 4:

Note that I've already added the necessary PIC changes to 6l, guarded by the -shared
flag. I suppose darwin (10.6) could re-use the PIC mode, but since RIP-relative
addressing excludes other useful addressing modes the resulting code size will grow,
which is probably not an acceptable tradeoff.
@bradfitz

This comment has been minimized.

Copy link
Member

commented Mar 28, 2013

Comment 5:

Considering the increasingly few people who a) use 10.6, b) run servers or otherwise
care about the binary size or performance on 10.6, I wouldn't worry about it.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

commented Mar 28, 2013

Comment 6:

Either way I think it might be useful to use RIP addressing when possible--when there is
no indexing or scaling.  I think the resulting instruction will be one byte shorter.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

commented Mar 29, 2013

Comment 7:

This issue was closed by revision 3197be4.

Status changed to Fixed.

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015

@rsc rsc removed the go1.1 label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
6 participants
You can’t perform that action at this time.