cmd/ld: cannot link objective-C code

[rogpeppe]

When cgo is used to compile objective-C code (see also CL 4476049), the resulting
objects cannot be linked.
I get errors like this:

_test/tst-go.nowhere.com/tst.a(tst.cgo2.o)(__DATA/__objc_classrefs): unhandled
relocation for OBJC_CLASS_$_NSApplication (type 20 rtype 120)

Given that it is necessary to use Objective-C to interact with much of the Mac OS system
functionality (e.g. graphics), it would be nice to be able to fix this.

Attached is a package that demonstrates the problem (gotest to try).

6g darwin 502384dd99e8+ tip

Attachments:

1. tstcgo.zip (788 bytes)

[robpike]

Comment 1:

Labels changed: added cgo.

Status changed to Accepted.

[robpike]

Comment 2:

Owner changed to @rsc.

[rsc]

Comment 3:

thanks for the CL

[rsc]

Comment 4:

Labels changed: added priority-later, removed priority-medium.

[gopherbot]

Comment 6 by mcphail_colin@hotmail.com:

I'm seeing something very similar with C-compiled code:
/Users/...../pkg/darwin_amd64/cmcp/gcd.a(queue.cgo2.o)(__DATA/__const): unhandled
relocation for _dispatch_queue_attr_concurrent (type 23 rtype 120)

[rsc]

Comment 9:

Labels changed: added go1.1.

[rsc]

Comment 10:

Labels changed: added size-l.

[skelterjohn]

Comment 11:

This seems off to be. My go.wde cocoa implementation
(https://github.com/skelterjohn/go.wde/tree/master/cocoa) makes heavy use of a framework
I wrote using ObjC. I use some straight C code as an intermediary, but there were no
linking problems.

[cookieo9]

Comment 12:

#11: I believe the issue is about using cgo & the go tool to build the ObjC part and
thus the entire package becomes go-gettable (and possibly self-contained), not as your
package does where the user must install an xcode-built framework first.

[rsc]

Comment 13:

We will be fixing this by making gcc do the final link, and then 6l doesn't need to know
about all these terrible details. Getting that working is issue #4069.

Status changed to Duplicate.

Merged into issue #4069.