Closed FuzzOli87 closed 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.
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.pkg
from 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
@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.
@FuzzOli87 Have you tried homebrew? This works for me (using https://github.com/Homebrew/homebrew-core/pull/32204).
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.
@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).
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?
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.4
Which might be related to the issues the homebrew-core peeps are having.
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.
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.
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.)
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.
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
).
Ah, right. What if add those 3 lines to third-party/CMakeLists.txt
before project(NVIM_DEPS)
?
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).
Ok, then someone will need to do some more investigation. :)
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.)
@clason Both builds crash for me though
@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.
Solved for me by installing the newest version of Xcode and its tools. π
I have Xcode 10.0 with its tools installed and the build fails similarly. nvimbuild.txt
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
ok, one more working recipe just arrived :)
xcode-select --install
make distclean
SDKROOT
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.14
it works without installing the compatibility package mentioned above, though I'm still not sure who to blame; will investigate this later
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.4
cc -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 value
MACOSX_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
Nice. Can you send a patch?
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)
I'm using macOS Monterey 12.2.1, and I encountered build error minutes ago. This resolves my problem:
sudo make distclean
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 --install
and the license accepting stuff. But so far nothing has worked.