go: runtime/cgo: fails to build after updating to Mojave
What version of Go are you using (go version
)?
go version go1.11 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/foo/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Volumes/DailySD/SD_Dev"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/fj/yby80m4x1pq1nzvfvd1hplhw0000gn/T/go-build110153853=/tmp/go-build -gno-record-gcc-switches -fno-common"
GCC
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
What did you do?
update macOS to mojave, install go, vscode for Developement.
An error that did not get offended when go test was done within an existing project occurred. It is below.
# runtime/cgo
_cgo_export.c:3:10: fatal error: 'stdlib.h' file not found
If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best.
What is missing, please help me.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 21
- Comments: 59 (8 by maintainers)
Shortly the way it worked on macOS Catalina in my case:
if someone facing this issue in catalina (10.15) try this.
export SDKROOT="$(xcrun --sdk macosx --show-sdk-path)"
This does the magic.
Found the solution with this one
Thanks a lot! This work for me!
FYI - Had the same issue, tried everything above
However, the file, mentioned in comments above…
seems to be no longer available, with the latest version of xcode, see the New Features section here https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes
Solution:
Running
brew doctor
, as per the instructions below…So, using the script provided in the link below, which simply moves the files one at a time to another folder, fixed the issue for me https://github.com/SOHU-Co/kafka-node/issues/881#issuecomment-396197724
Repeated below…
You can try
xcode-select --install
@raxod502 Thanks for the advice. In this case, just unlinking
LLVM
temporally fixes this issue:That is what I thought. However, I just did some more testing and it appears that I was wrong.
/usr/bin/gcc
that ships with macOS can find the standard headers./usr/bin/clang
that ships with macOS can find the standard headers./usr/local/bin/gcc-9
that is installed by Homebrew can find the standard headers./usr/local/opt/llvm/bin/clang
that is installed by Homebrew cannot find the standard headers.(It did not occur to me that the behavior might be different between different compilers.)
So what I conclude is that cgo defaults to using clang as the compiler, and since I have installed clang from Homebrew and added it to my PATH, this causes the error. Therefore, the problem lies with either Homebrew or LLVM – not Go – and somebody should open an issue against one of those projects.
I’m sorry for spreading misinformation here. Thanks for your help.
Solution: go to https://developer.apple.com/download/more/ (Apple Developer account required) and download “Command Line Tools (macOS 10.14) for Xcode 10.2.1” (or equivalent for your OS version). Extract that package, which installs the
macOS_SDK_headers_for_macOS_10.14.pkg
package to/Library/Developer/CommandLineTools/Packages
, which you can then extract separately. That finally gets you your/usr/include
back.It works for me because I’ve used clang in anaconda. (macOS Big Sur 11.1)
Removing brew llvm helped me.
brew remove llvm
I think it was not searching for the headers in the right spot.I have the same issue and
xcode-select --install
did not solve the problemIt works for me (Big Sur 11.1)
This fixed my issue. The path for Clang was coming up as
/user/local/bin/clang
, instead of/user/bin/clang
, guessing because I had once used Homebrew to install a version of Clang.Maybe this can help someone: https://github.com/mattn/go-sqlite3/issues/481#issuecomment-355717133
on mojave 10.14.4, it works. command line> open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
Yes, there is really nothing that can be done in the Go tools. The Go tools never read system headers themselves, and they never read /usr/include. Instead, they invoke the C compiler, and expect the C compiler to read those headers. You can see the C compiler that they will invoke by using
go env CC
, and you can see precisely what the Go tool does by usinggo build -x
.set Environment Varibles in xcode clang target arguments:
SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk
worked for me!
reinstall x-code commandline tools :
and then
it work for me !
System headers have moved
Apple have changed the default location of the system headers with macOS 10.14, Mojave, and Xcode 10:
it works.
@ianlancetaylor I understand what you are saying, but I think Apple’s implication is that the Go build system needs to pass an extra
-I
argument to the C compiler with the path to the macOS SDK. Yes, that’s completely ridiculous – but what is the alternative? Every single user of Go on macOS needs to exportC_INCLUDE_PATH
, or …?It is an unfortunate fact that the C compiler cannot find
stdlib.h
on macOS anymore, at least by default. So while it makes perfect sense to say “it is your own responsibility to make sure the compiler can findstdlib.h
”, the sad truth is that this means every single Go developer on macOS would be required to take manual steps to get Go working properly.An alternative solution would be for Homebrew to do something to fix this problem in general, but I don’t know what the options look like for that.
Unfortunately, that package appears to no longer exist as of a recent update. What can I do?
@ianlancetaylor I totally am on your side here, but unfortunately Apple has made it clear they want every project to update their build tooling to work with the weird new SDK system:
So unfortunately I think this is a bug in Go, unless you want to drop support for macOS.
This fix it for me!
Nice
I was seeing the same issue but that was due to GCC, which I install using
apk add build-base