Closed FuzzOli87 closed 5 years ago
jamessan
commented
5 years ago I would suggest trying make distclean first. From what I've read, Mojave has moved standard header files out of /usr/include, so CMake may need to re-run to find where they are.
If that doesn't work, there's not much we can do. This is clearly a macOS issue, not an nvim issue.
clason
commented
5 years ago Starting with Mojave, the headers are no longer installed under /usr/include/ by default -- look under Command Line Tools -> New Features in the release notes.
Running
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkgfrom the command line fixes the issue (at least for me and using brew).
The release notes also states that this compatibility package will no longer be provided in the near future, so the build system on macOS will have to be adapted to look for headers in the SDK, making this (at that future point) indeed an nvim issue (if you do not want to punt this to homebrew). @jamessan
FuzzOli87
commented
5 years ago @jamessan That did not work. What @clason recommended got me past that struggle.
@clason This got me closer to it! It got passed that error but now it's failing somewhere else and I'm not really sure where.
clason
commented
5 years ago @FuzzOli87 Have you tried homebrew? This works for me (using https://github.com/Homebrew/homebrew-core/pull/32204).
jamessan
commented
5 years ago the build system on macOS will have to be adapted to look for headers in the SDK
Any help making that happen is appreciated -- pointers to documentation or PRs. I'm not familiar with what would be needed here.
clason
commented
5 years ago @jamessan I'd have to understand neovim's build system first; from the release notes linked above, the headers are now no longer installed in /usr/include but in either
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk(with a full Xcode install) or
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk(with only the command line tools installed). Having to special case macOS (>=10.14) will be a pain...
In the meantime, I've added this step to the Building section of the wiki for those compiling neovim themselves (i.e., not using homebrew, which gives an explicit error message pointing to the missing headers and the compatibility file).
jamessan
commented
5 years ago According to CMake's documentation, it seems the end-user building the software should be setting CMAKE_OSX_SYSROOT appropriately for the SDK they're targeting.
However, it's supposed to default to $SDKROOT or, if that's not set, get calculated based on $MACOSX_DEPLOYMENT_TARGET. Are these no longer set in your build environment?
FuzzOli87
commented
5 years ago Homebrew/homebrew-core#32204
No I've always just built from source. I had a reason at some point but I probably don't need that anymore. The error I'm getting is:
With particular interest here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -g -L/usr/local/opt/openssl/lib -o host/minilua host/minilua.o -lm
ld: library not found for -lgcc_s.10.4Which might be related to the issues the homebrew-core peeps are having.
FuzzOli87
commented
5 years ago After some digging, I finally got it to build locally by running:
export MACOSX_DEPLOYMENT_TARGET=10.14
I was led to this by:
https://github.com/Homebrew/homebrew-core/issues/31483
Which led to this:
https://luajit.org/install.html
And finally, led to my experimentation which worked. I don't know anything about the build process or how/when this variable is set, if even, but that worked for me.
jamessan
commented
5 years ago Ok, well that correlates with the CMake documentation I linked earlier. I guess the question is why this isn't being set in your build environment.
My assumption (never having built anything on macOS) is that there are certain environment variables set based on the SDK you're building with, which CMake should be able to pick up. Maybe that's not the case and everyone used to just get away with it because the headers were installed to /usr/include.
In which case, maybe there's a "run terminal with SDK environment set" button somewhere that people should be using to perform builds. I know there is on the Windows side of the world, since you can have multiple SDKs installed, so you start a cmd prompt targeting the SDK you're trying to build with.
clason
commented
5 years ago Note that @FuzzOli87 seems to have had already installed the compatibility package at this point.
macOS is a bit of a walled garden; Apple assumes that people are building macOS apps with the macOS tools, which know the correct path... (I share your suspicion on why other things mostly "just work".) I myself rely on homebrew for compiling open source software.
Unfortunately, there's no "developer terminal"; the used developer environment is selected from the command line via an xcode-select utility (or from within Xcode, if that is installed). This includes the SDKs; the command line tools should automatically pick up the right SDK (I have no idea how cross-compilation works on macOS). Why this doesn't happen here is not clear to me; either (a not Mojave-aware version of) cmake overrides this with "default" settings, or some settings were cached before upgrading to Mojave and were still being picked up.
Ideally, it suffices to do
MACOSX_DEPLOYMENT_TARGET=10.14 make(and, if so, add this to the build instructions), but it's apparently not that easy. (CMake seems to be picking up the correct SYSROOT, though, so something else must be going on.)
jamessan
commented
5 years ago If there's a way to query the running macOS for the version, then we could default MACOSX_DEPLOYMENT_TARGET to that, if it isn't already set.
jamessan
commented
5 years ago Does this diff help?
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 02b555d54..8fb213638 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,6 +2,10 @@
# intro: https://codingnest.com/basic-cmake/
# best practices (3.0+): https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
+if(APPLE AND NOT DEFINED ENV{MACOSX_DEPLOYMENT_TARGET} AND NOT DEFINED ENV{SDKROOT})
+ set(CMAKE_OSX_DEPLOYMENT_TARGET ${CMAKE_SYSTEM_VERSION})
+endif()
+
cmake_minimum_required(VERSION 2.8.12)
project(nvim C)
@jamessan Unfortunately not.
But that's not the problem -- I can compile libuv and luajit individually from the respective source directories in .deps/build/src (setting the $MACOSX_DEPLOYMENT_TARGET for luajit first), but make deps fails (with conftest complaining about 'stdio.h' file not found).
jamessan
commented
5 years ago Ah, right. What if add those 3 lines to third-party/CMakeLists.txt before project(NVIM_DEPS)?
clason
commented
5 years ago Still no luck 😞 (And setting the environment variable manually before building also doesn't work -- for some reason, it must get overwritten or discarded downstream.)
I'm just doing make from the top-level directory of a fresh checkout of the neovim repo, by the way (which works in Linux).
jamessan
commented
5 years ago Ok, then someone will need to do some more investigation. :)
clason
commented
5 years ago And probably see why homebrew's https://github.com/Homebrew/homebrew-core/blob/master/Formula/neovim.rb works while make doesn't :)
(Honestly, I'm fine with relying on homebrew for compiling neovim on macOS. And if anything needs to be changed on the neovim side to keep this working later on, I'm sure the brew community will open a much more detailed issue.)
danilo-augusto
commented
5 years ago @clason Both builds crash for me though
FuzzOli87
commented
5 years ago @clason I installed the header stuff that you pointed too earlier. And I also ran brew reinstall to reinstall everything, including the listed dependencies to build neovim.
@jamessan If you need to find out anything else about my environment, let me know and I can provide.
danilo-augusto
commented
5 years ago Solved for me by installing the newest version of Xcode and its tools. 🎉
ChrisBFusion
commented
5 years ago I have Xcode 10.0 with its tools installed and the build fails similarly. nvimbuild.txt
zhaozg
commented
5 years ago I meet same issue after install Mojave
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg , issue keep existsudo xcode-select -s /Library/Developer/CommandLineTools , issue keep existGot it, Update makefile for Luajit will pass. Success build after remove https://github.com/LuaJIT/LuaJIT/blob/master/src/Makefile#L301-L303 lines
dm1try
commented
5 years ago ok, one more working recipe just arrived :)
xcode-select --installmake distcleanSDKROOT and MACOSX_DEPLOYMENT_TARGET env vars explicitly on building
make SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk MACOSX_DEPLOYMENT_TARGET=10.14it works without installing the compatibility package mentioned above, though I'm still not sure who to blame; will investigate this later
dm1try
commented
5 years ago Hi, there! So I did some investigation^
Actually, the providing two additional environment variables(MACOSX_DEPLOYMENT_TARGET and SDKROOT) points that we have ✌️ problems :
luajit sets MACOSX_DEPLOYMENT_TARGET to 10.4 if it is not provided(see the docs, code).
IMHO the implicit setting of this value leads to inconsistency(some components are built with the default target if the value is not provided, but the luajit is built with 10.4)
for this target value on Mojave clang(in cooperation with ld) cannot find system lib:
# 10.4
MACOSX_DEPLOYMENT_TARGET=10.4 cc -lgcc_s.1
ld: library not found for -lgcc_s.10.4cc -lgcc_s.1 Undefined symbols for architecture x86_64: "_main", referenced from: ...
So if `MACOSX_DEPLOYMENT_TARGET` is not provided we can set `CMAKE_OSX_DEPLOYMENT_TARGET` value to it while building `luagit` here:
https://github.com/neovim/neovim/blob/e568ac7a68d3b7a05af34d931fad1d2c18fa396c/third-party/cmake/BuildLuajit.cmake#L53-L54
In the case `MACOSX_DEPLOYMENT_TARGET/CMAKE_OSX_DEPLOYMENT_TARGET` is empty, it looks like `clang` will fallback to a default valueMACOSX_DEPLOYMENT_TARGET= cc -lgcc_s.1 Undefined symbols for architecture x86_64: "_main", referenced from: ...
So all components should depend on `CMAKE_OSX_DEPLOYMENT_TARGET` at least, otherwise, a user must provide `MACOSX_DEPLOYMENT_TARGET` explicitly for solving the issue^
2. the second issue is related to the latest changes in the management of system headers(they moved from `/usr/include` to MacOS SDK path; was also mentioned above). the trick is what how this path is resolved by `clang`.
if you run `clang` directly from toolchain without providing `isysroot` option it cannot resolve the sdk path, that leads to the build errors:configure:3481: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -o conftes conftest.c >&5 configure:3485: $? = 0 configure:3507: result: configure:3529: checking whether we are cross compiling configure:3537: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -o conftes conftest.c >&5 conftest.c:11:10: fatal error: 'stdio.h' file not found
host/minilua.c:34:10: fatal error: 'math.h' file not found
So to make the compiler happy we should provide sdk path to the compiler in `isysroot` option(does it sound like a proper solution?). On my machine those values are properly resolved by `cmake`cmake -LA &> /dev/null| grep 'COMPILER|SDK' CMAKE_C_COMPILER:FILEPATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc CMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
but sdk path is not passed to the compiler.
OK. But why does the explicit `SDKROOT` value also solve the problem? `SDKROOT` is just another way to pass sdk path to the `clang`; internally it is used by `xcrun` tool xcrun provides a means to locate or invoke developer tools from the command-line, without requiring users to modify Makefiles or otherwise take inconvenient measures to support multiple Xcode tool chains. SDKROOT
Specifies the default SDK to be used when looking up tools (some tools may have SDK specific versions).
....
For example, if xcrun is used to invoke clang via:
xcrun --sdk macosx clang test.c
then xcrun will provide the full path to the macosx SDK in the environment variable SDKROOT. That in turn will be used by clang(1) to automatically select that SDK when compiling the test.c file.
so according to all this information, the updated snippet to make the build on Mojave is:
```bash
# make clang happy and trick luajit 😄
make SDKROOT=`xcrun --show-sdk-path` MACOSX_DEPLOYMENT_TARGET=I'm still not sure about the proper solution for the second problem, though
justinmk
commented
5 years ago Nice. Can you send a patch?
dm1try
commented
5 years ago Nice. Can you send a patch?
sure, I'm going to continue tomorrow and make a PR(will check the possible solution for the second problem)
nyngwang
commented
2 years ago I'm using macOS Monterey 12.2.1, and I encountered build error minutes ago. This resolves my problem:
sudo make distclean
Sleepful
commented
2 months ago thank you @nyngwang
Attempting to build from master fails on OSX mojave.
Actual behaviour
make CMAKE_BUILD_TYPE=Release
build output
``` In file included from unibilium.c:22: ./unibilium.h:25:10: fatal error: 'stdio.h' file not found #includeExpected behaviour
For the build process to succeed.
I tried doing the typical xcode stuff
xcode-select --installand the license accepting stuff. But so far nothing has worked.