Trying to build a simple Go library that spins up an http.Server from a call in C, but it fails to compile the C against the produced library object. Similar examples without involving http work just fine.
$ go version
go version devel +a2aaede Wed Jun 17 14:55:39 2015 +0000 darwin/amd64
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7m armv7em
LTO support using: LLVM version 3.5svn
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
Error:
$ gcc -o gohttp-c examples/c/main.c gohttplib.a -lpthread
Undefined symbols for architecture x86_64:
"_CFArrayGetCount", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_CFArrayGetValueAtIndex", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_CFDataAppendBytes", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_CFDataCreateMutable", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_CFDataGetBytePtr", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
__cgo_6dbb806e9976_Cfunc_CFDataGetBytePtr in gohttplib.a(000003.o)
(maybe you meant: __cgo_6dbb806e9976_Cfunc_CFDataGetBytePtr)
"_CFDataGetLength", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
__cgo_6dbb806e9976_Cfunc_CFDataGetLength in gohttplib.a(000003.o)
(maybe you meant: __cgo_6dbb806e9976_Cfunc_CFDataGetLength)
"_CFRelease", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
__cgo_6dbb806e9976_Cfunc_CFRelease in gohttplib.a(000003.o)
(maybe you meant: __cgo_6dbb806e9976_Cfunc_CFRelease)
"_SecKeychainItemExport", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_SecTrustCopyAnchorCertificates", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_kCFAllocatorDefault", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [example-c] Error 1
More thorough description and full code examples are available in this StackOverflow question.
This might be related to the OSX/darwin arch as a commenter was able to get it working on Ubuntu.
Does it work if you add "-framework CoreFoundation -framework Security" to the gcc link line? Probably just before the -pthread option.
I took those options from the # cgo LDFLAGS line in crypto/x509/root_cgo_darwin.go. I don't see a way for us to add those lines to the final command line, as that is not under our control. I don't know if there is a way to avoid needing them at all. There may be Darwin-specific approaches that I am not aware of.
@ianlancetaylor Aha, this does the trick indeed:
gcc -o gohttp-c examples/c/main.c gohttplib.a -framework CoreFoundation -framework Security -lpthread
(I think you have a mispaste in your comment with "http://go/gocomments#TOC-ErrorStrings")
Fixed the mispaste, sorry about that.
I'm going to postpone this to 1.6. I don't know what to do about it, but maybe someone can think of something.
Sounds like this is a documentation issue. I don't know of any magic way to convince the linker to automatically link a library. And if Ian doesn't, there probably isn't one.
@ianlancetaylor, I think this is a documentation issue, but where do we put the note that the final link will need to include libraries used by the Go sources? Is there something other than your build modes doc?
I started to write docs in helpBuildmode in cmd/go/help.go, but it's too horrible to make people dig into the crypto/x509 sources to figure out what options to pass. I think what we need to do is have a way for cmd/go to print out the accumulated cgo LDFLAGS from the packages added to a c-archive or c-shared build. Then people can in principle capture that at the time they build the archive/shared library (probably using a Makefile), and pass it on their final linker command line.
So, postponing until 1.7.
As a follow up to this, there is a bigger related issue on iOS. The following functions exist on macOS but not on iOS:
SecTrustSettingsCopyCertificates
SecTrustSettingsCopyTrustSettings
SecCertificateCopyNormalizedSubjectContent
SecCertificateCopyNormalizedIssuerContent
SecItemExport
So adding -framework Security doesn't help there. This means that any code that imports net/http (or anything else that uses crypto/x509) can not be used on iOS.
Most helpful comment
As a follow up to this, there is a bigger related issue on iOS. The following functions exist on macOS but not on iOS:
SecTrustSettingsCopyCertificates
SecTrustSettingsCopyTrustSettings
SecCertificateCopyNormalizedSubjectContent
SecCertificateCopyNormalizedIssuerContent
SecItemExport
So adding -framework Security doesn't help there. This means that any code that imports net/http (or anything else that uses crypto/x509) can not be used on iOS.