Build for arm64 Macs #12624

qvacua · 2020-07-11T19:25:52Z

It compiles and runs without crashes. However, to compile, I had to add

DEPS_CMAKE_FLAGS += -DCMAKE_OSX_DEPLOYMENT_TARGET=11.00

to local.mk and do

make SDKROOT=`xcrun --show-sdk-path`

jamessan · 2020-07-11T20:39:05Z

CMakeLists.txt

@@ -352,7 +352,7 @@ if(CMAKE_C_COMPILER_ID STREQUAL "GNU" OR CMAKE_C_COMPILER_ID STREQUAL "Clang")
  add_definitions(-D_GNU_SOURCE)
 endif()

-if(CMAKE_SYSTEM_NAME STREQUAL "Darwin" AND CMAKE_SIZEOF_VOID_P EQUAL 8)
+if(CMAKE_SYSTEM_NAME STREQUAL "Darwin" AND CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL "x86_64" AND CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT PREFER_LUA)


It seems this isn't needed at all for LuaJIT >= 2.1.0 beta3. That would be a better check than adding the architecture.

Changed the check to look for LUAJIT_VERSION LESS "2.1.0-beta3".

jamessan · 2020-07-11T20:40:55Z

third-party/patches/libvterm-arm64-darwin.patch

+++ b/bin/vterm-ctrl.c
+@@ -1,4 +1,4 @@
+-#define _XOPEN_SOURCE 500  /* strdup */
+#define _XOPEN_SOURCE 600  /* strdup */


This should be fixed upstream. Cc @leonerd

Reverted the commit and created neovim/libvterm#6.

Updated the PR to use the newest revision of libvterm and adapted a line of code.

and adapted a line of code.

That's an unreleased API change. We shouldn't be pulling that in. @leonerd, any chance of a maintenance release while the mainline stabilizes?

Ups, reverted the commit.

jamessan · 2020-08-06T19:32:53Z

@leonerd Can you please release a new libvterm with the _XOPEN_SOURCE fix? Also, it should be made unconditional. That change is in no way specific to macOS.

leonerd · 2020-08-22T14:56:02Z

0.1.4 now at http://www.leonerd.org.uk/code/libvterm/

qvacua · 2020-08-22T18:14:19Z

Updated the PR. I'll test on an arm64 Mac that it really builds next week once I'm back at home.

clason · 2020-08-26T10:34:33Z

@jamessan probably a candidate for backporting to release-0.4? (same for #12676)

Maybe it would be a good idea to separate out the libvterm bump for easier backporting (I assume the LuaJIT bump and ARM setup don't really make sense to backport.)

clason · 2020-08-26T10:38:30Z

@qvacua I just tested this on non-ARM macOS and got

/Library/Developer/CommandLineTools/usr/bin/make -C src
Makefile:319: *** missing: export MACOSX_DEPLOYMENT_TARGET=XX.YY.  Stop.
make[1]: *** [src/luajit] Error 2

The build works correctly (modulo the _XOPEN_SOURCE fix) without these changes.

EDIT This is due to the following commit pulled in now: LuaJIT/LuaJIT@8961a92
So the corresponding CMake file needs to be adapted here:

neovim/third-party/cmake/BuildLuajit.cmake

Line 69 in 4320296

    
               set(DEPLOYMENT_TARGET "MACOSX_DEPLOYMENT_TARGET=${CMAKE_OSX_DEPLOYMENT_TARGET}")

It seems that you can no longer "trick" the LuaJIT build system with an empty MACOSX_DEPLOYMENT_TARGET but actually have to specify a valid target now. Would it make sense to provide a default here?
I don't know what the correct (non-ARM) version would be? The same as LuaJIT's default, 10.4, doesn't work, but 10.9 seems to work:

   if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
     if(CMAKE_OSX_DEPLOYMENT_TARGET)
       set(DEPLOYMENT_TARGET "MACOSX_DEPLOYMENT_TARGET=${CMAKE_OSX_DEPLOYMENT_TARGET}")
     else()
       set(DEPLOYMENT_TARGET "MACOSX_DEPLOYMENT_TARGET=10.9")
     endif()
    else()
      set(DEPLOYMENT_TARGET "")
    endif()

This additional change makes this patch build correctly on Intel macOS, at least; lua seems to work fine in a cursory test. (You'd need to add a case for ARM hardware setting DEPLOYMENT_TARGET to 11.0, of course.)

Otherwise this change for the macOS build (that you now have to set the CMAKE_OSX_DEPLOYMENT_TARGET environment variable) should be documented in the build instructions (and in "following HEAD").

EDIT3 Out of interest, I also checked Linux x86_64; there the patch (especially the bumped LuaJIT) builds fine out of the box.

EDIT4 Testing a bit further, it seems there are in fact other changes in LuaJIT behavior -- for example, math.max seems to behave differently with the new version, leading to errors in lua plugins.

Can you comment on the LuaJIT bump, by the way? Is that a released (beta) version?

jamessan · 2020-08-27T15:23:41Z

Maybe it would be a good idea to separate out the libvterm bump for easier backporting

Agreed. Let's do that first, since it's a clean and obvious fix and then there can be follow up work for other issues specific to the macOS/arm problems.

justinmk · 2020-08-30T05:24:55Z

third-party/CMakeLists.txt

-set(LIBVTERM_URL https://github.com/neovim/libvterm/archive/65dbda3ed214f036ee799d18b2e693a833a0e591.tar.gz)
-set(LIBVTERM_SHA256 95d3c7e86336fbd40dfd7a0aa0a795320bb71bc957ea995ea0e549c96d20db3a)
+set(LIBVTERM_URL http://www.leonerd.org.uk/code/libvterm/libvterm-0.1.4.tar.gz)
+set(LIBVTERM_SHA256 bc70349e95559c667672fc8c55b9527d9db9ada0fb80a3beda533418d782d3dd)


yikes, no https? I really wish git-bzr did not mess up the hashes, that is the main problem with https://github.com/neovim/libvterm as a mirror . OTOH leonerd.org.uk has failed dozens of builds from network errors...

No, leonerd.org.uk doesn't support https... (I checked for #12797)

What is the issue with the hashes? That they have to be recomputed manually?

What is the issue with the hashes? That they have to be recomputed manually?

somehow git-bzr changes the hashes every time we update the mirror: https://github.com/neovim/bot-ci/blob/c799c16b003db67e353542ee7f1494731931dc6b/ci/sync-mirrors.sh#L46

not sure if we're using git-bzr wrong or if bzr just sucks.

actually it seems like that maybe isn't happening anymore ? if so then there's no reason to use leonerd.org.uk ...

except that the mirror isn't updated yet...

Ups, I did not notice the missing s in http. I'll update the PR to use neovim/libvterm@54c03b2.

@qvacua the bump was already merged in #12797, by the way, so you can just rebase.

qvacua · 2020-08-31T17:19:50Z

Neovim builds successfully and seems to work w/o problems on an arm64 Mac.

@clason : I bumped the LuaJIT version since there were recent commits which fixed the build on arm64 Macs. I am not sure about incompatibilities introduced by the bump though.

Regarding setting the deployment target: IMO, your suggestion is a good one. @justinmk , @jamessan: What is the officially supported minimum deployment target of Neovim? I guess 10.9, which @clason suggested, would also depend on the version of Xcode used. I think setting a default deployment target should be done in a different PR?

For the sake of completeness: AFAICS, there are usually three "sources" for deployment target when building on macOS

libintl is usually installed by brew with deployment target equal to the macOS you're currently using.
Setting DEPS_CMAKE_FLAGS="-DCMAKE_OSX_DEPLOYMENT_TARGET=xyz" will set the deployment target of LuaJIT, but not other dependencies as it seems. Other dependencies simply do not have that information which can be checked by otool by looking for the LC_VERSION_MIN_MACOSX keyword.
Setting MACOSX_DEPLOYMENT_TARGET=xyz set the deployment target for other dependencies and the nvim binary itself.

It's not a big deal that the deployment targets of the dependencies and the nvim binary are different since no macOS specific APIs are used, I guess, but you most probably will get a warning at the end when building Neovim.

mikelxc · 2020-11-17T09:21:55Z

Tried to build on MacBook Pro M1, LuaJIT failed to work out of box, an easy fix will be create a symlink for luajit in the bin folder and give it the name Lua.

However, even after that fix, still failed to build with error code

cd /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/runtime/pack/dist/opt/matchit && /opt/homebrew/Cellar/cmake/3.18.4/bin/cmake -E copy_directory /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/runtime/pack/dist/opt/matchit /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/runtime/pack/dist/opt/matchit
cd /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/runtime && /opt/homebrew/bin/luajit /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/scripts/genvimvim.lua /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/src/nvim /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/runtime/syntax/vim/generated.vim /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/funcs_data.mpack
cd /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/runtime && /opt/homebrew/Cellar/cmake/3.18.4/bin/cmake -E copy_directory /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/runtime/doc doc
cd /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/runtime/pack/dist/opt/vimball && /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ doc -c quit
cd /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/runtime/pack/dist/opt/matchit && /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ doc -c quit
/bin/sh: line 1: 73068 Killed: 9               /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ doc -c quit
/bin/sh: line 1: 73069 Killed: 9               /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ doc -c quit
make[2]: *** [runtime/pack/dist/opt/matchit/doc/tags] Error 137
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [runtime/pack/dist/opt/vimball/doc/tags] Error 137
cd /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/runtime && /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ ++t\ doc -c quit
/bin/sh: line 1: 73071 Killed: 9               /tmp/neovim-20201117-69850-1umpkrt/neovim-0.4.4/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ ++t\ doc -c quit
make[2]: *** [runtime/doc/tags] Error 137
make[1]: *** [runtime/CMakeFiles/runtime.dir/all] Error 2
make: *** [all] Error 2

clason · 2020-11-17T09:25:50Z

You are trying to build an older released version that doesn't have the necessary patches, and using homebrew to boot. Can you please try building master (git clone https://github.com/neovim/neovim.git, cd neovim, make)?

mikelxc · 2020-11-17T11:20:38Z

Got the same error code for both brew install Neovim --HEAD and building from master

clason · 2020-11-17T11:29:21Z

Thank you for testing. So it looks like neovim actually builds correctly, but the binary crashes or hangs(?) afterwards when generating help tags.

Could you try running env VIMRUNTIME=./runtime ./build/bin/nvim and see what happens?

mikelxc · 2020-11-17T11:32:40Z

Thank you for testing. So it looks like neovim actually builds correctly, but the binary crashes or hangs(?) afterwards when generating help tags.

Could you try running env VIMRUNTIME=./runtime ./build/bin/nvim and see what happens?

This is what I get

[1]    42097 killed     env VIMRUNTIME=./runtime ./build/bin/nvim

I tried to delete the whole folder and clone it again and rebuilt it with
export MACOSX_DEPLOYMENT_TARGET=11.0
Still get the same error.

clason · 2020-11-17T11:36:23Z

Can you get a stacktrace or something? That's not a lot to go on...

(And just to make sure -- you are using this PR and following the instructions in the description?)

mikelxc · 2020-11-17T11:47:47Z

Not 100% sure if I'm on the right track, but this is what I got

Undefined symbols for architecture arm64:
  "_custom_ui_autocmds_groups", referenced from:
      _apply_autocmds_group in fileio.c.o
  "_custom_ui_rpcevent_subscribed", referenced from:
      _nvim_subscribe in vim.c.o
  "_custom_ui_start", referenced from:
      _ui_builtin_start in ui.c.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

qvacua · 2020-11-17T20:18:58Z

@mikelxc: At least on the DTK, the master does not run and is killed immediately similar to what you wrote. The reason is when the LuaJit library is linked, master sets some parameters which do not work on arm64 Macs. This PR sets those parameters only when appropriate. I've successfully compiled and run the branch of this PR on the DTK.

qvacua · 2020-11-17T20:23:53Z

BTW: Compilation succeeds only when DEPS_CMAKE_FLAGS += -DCMAKE_OSX_DEPLOYMENT_TARGET=11.00 is set as in my first comment in this PR.

qvacua · 2020-11-17T20:27:54Z

@mikelxc: The _custom_ui_autocmds_groups errors are specific to the master branch of my fork (for VimR). You should checkout the build-arm64-mac branch.

mikelxc · 2020-11-18T12:57:12Z

It now builds without a problem after switching to the "build-arm64-mac" branch!

stefanpenner · 2020-11-24T02:31:35Z

For anyone having issues, or simply lazy (like me), the following steps can likely be blindly followed:

git clone git@github.com:neovim/neovim
cd neovim
git remote add qvacua git@github.com:qvacua/neovim.git
echo "DEPS_CMAKE_FLAGS += -DCMAKE_OSX_DEPLOYMENT_TARGET=11.00" >> local.mk
make SDKROOT=`xcrun --show-sdk-path`

Resulting in a functioning nvim at ./build/bin/nvim, and it is correctly built as arm64

~/s/n/neovim (build-arm64-mac)> file build/bin/nvim 
build/bin/nvim: Mach-O 64-bit executable arm64

menssen · 2020-11-24T15:43:09Z

It's amazing how when somebody says "if you're lazy, just copy and paste this!" you tend to just do it, even when you know there's obviously a step missing. So if anybody else is as lazy as I was, here is the last comment, slightly corrected. (Either way, thanks @stefanpenner!)

git clone git@github.com:neovim/neovim
cd neovim
git remote add qvacua git@github.com:qvacua/neovim.git
git fetch qvacua
git checkout build-arm64-mac
echo "DEPS_CMAKE_FLAGS += -DCMAKE_OSX_DEPLOYMENT_TARGET=11.00" > local.mk
make SDKROOT=`xcrun --show-sdk-path`

jamessan · 2020-11-28T18:49:03Z

Looks like LuaJIT/LuaJIT@ff34b48 brought out some issues in our test stack -- still not sure if it's in our code or busted.

Once we get a handle on those, we should be able to merge this PR.

mattnibs · 2020-12-11T16:55:43Z

@jamessan is there any way I can help this along? Would be great to get this into master.

jamessan · 2020-12-11T18:06:43Z

We need to figure out why some of our tests are failing like below with this PR and fix it.

  [  ERROR   ] 9 errors, listed below:
  [  ERROR   ] test/functional/plugin/lsp_spec.lua @ 265: LSP basic_init test should verify capabilities sent
  test/helpers.lua:73: exit code
  Expected objects to be the same.
  Passed in:
  (number) 101
  Expected:
  (number) 0
  ------------------------------------------------------------------------------
  $NVIM_LOG_FILE: Xtest-fake-lsp.log
  (last 999 lines)
  ERROR LSP: test/functional/fixtures/fake-lsp-server.lua:29: assert_eq failed: left == "\"shutdown\"", right == "\"test\""
  ERROR LSP: test/functional/fixtures/fake-lsp-server.lua:29: assert_eq failed: left == "{\
  ------------------------------------------------------------------------------
  
  
  stack traceback:
  	test/helpers.lua:73: in function 'eq'
  	test/functional/plugin/lsp_spec.lua:277: in function 'on_exit'
  	test/functional/plugin/lsp_spec.lua:109: in function 'test_rpc_server'
  	test/functional/plugin/lsp_spec.lua:269: in function <test/functional/plugin/lsp_spec.lua:265>

clason · 2020-12-11T18:11:56Z

In particular, why the capabilities table is sorted differently in the two code paths that are compared there.

mattnibs · 2020-12-13T02:29:01Z

I believe I have a fix for this here: qvacua#1

(Wasn't sure the appropriate was of including this with this pr).

This is properly handled in LuaJIT now and setting causes "Malformed Mach-o file" error when running the resulting binary on arm64 Macs.

LuaJIT build now requires specifying a deployment target, so use the same baseline as our nightly builds. Co-authored-by: Christian Clason <christian.clason@uni-due.de>

Apparently the new version of LuaJIT changed the consistency with which it sorted table dictionaries. IIRC lua sorts dictionary keys by memory address, so it would appear that the reasons tests were previously passing was because of a differentiation in the implementation of the lua runtime. Ensure that array fields in the lsp protocol tables are consistently created, by using ipair when generating arrays for completionItemKind and symbolItemKind. For CodeActionKind, the current implementation includes both the keys and the values in the array. This is incorrect. Ensure that only the values are included in the array and sort them for consistency.

TC72 · 2020-12-14T10:28:36Z

It's amazing how when somebody says "if you're lazy, just copy and paste this!" you tend to just do it, even when you know there's obviously a step missing. So if anybody else is as lazy as I was, here is the last comment, slightly corrected. (Either way, thanks @stefanpenner!)
git clone git@github.com:neovim/neovim
cd neovim
git remote add qvacua git@github.com:qvacua/neovim.git
git fetch qvacua
git checkout build-arm64-mac
echo "DEPS_CMAKE_FLAGS += -DCMAKE_OSX_DEPLOYMENT_TARGET=11.00" > local.mk
make SDKROOT=`xcrun --show-sdk-path`

When I follow this I get:
FAILED: src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o

clason · 2020-12-14T10:52:31Z

@TC72 make sure to make distclean beforehand. Also, this PR is now merged, so if you update neovim to HEAD, you should only need the last two lines. If these don't work for you, please open a new issue with full information to reproduce this (especially your system).

Keating950 · 2020-12-14T14:40:41Z

@clason, for what it's worth, I didn't even need the last two lines to build successfully on my M1 mini.

TC72 · 2020-12-15T00:15:09Z

@clason, for what it's worth, I didn't even need the last two lines to build successfully on my M1 mini.

Is there any chance you could walk through exactly how you did it. I've tried everything and still can't get it to build. There's obviously something wrong with my setup if it's working for others.

yingzhu146 · 2020-12-17T00:37:54Z

ninja  -C build
ninja: Entering directory `build'
[301/321] Building C object src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o
FAILED: src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o 
/Library/Developer/CommandLineTools/usr/bin/cc -DINCLUDE_GENERATED_DECLARATIONS -DMIN_LOG_LEVEL=1 -DNVIM_MSGPACK_HAS_FLOAT32 -D_GNU_SOURCE -Dnvim_EXPORTS -Iconfig -I../src -Isrc/nvim/auto -Iinclude -I../.deps/usr/include/luajit-2.1 -isystem ../.deps/usr/include -isystem /opt/local/include -isystem /Library/Frameworks/R.framework/Headers -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -g -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -MD -MT src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o -MF src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o.d -o src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o -c ../src/nvim/tui/tui.c
../src/nvim/tui/tui.c:552:7: error: no member named 'i' in 'unibi_var_t'
      UNIBI_SET_NUM_VAR(data->params[0], standout);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Same here @TC72 - even after make distclean, and after deleting and pulling from master from fresh install

TC72 · 2020-12-17T07:18:38Z

ninja  -C build
ninja: Entering directory `build'
[301/321] Building C object src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o
FAILED: src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o 
/Library/Developer/CommandLineTools/usr/bin/cc -DINCLUDE_GENERATED_DECLARATIONS -DMIN_LOG_LEVEL=1 -DNVIM_MSGPACK_HAS_FLOAT32 -D_GNU_SOURCE -Dnvim_EXPORTS -Iconfig -I../src -Isrc/nvim/auto -Iinclude -I../.deps/usr/include/luajit-2.1 -isystem ../.deps/usr/include -isystem /opt/local/include -isystem /Library/Frameworks/R.framework/Headers -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -g -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -MD -MT src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o -MF src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o.d -o src/nvim/CMakeFiles/nvim.dir/tui/tui.c.o -c ../src/nvim/tui/tui.c
../src/nvim/tui/tui.c:552:7: error: no member named 'i' in 'unibi_var_t'
      UNIBI_SET_NUM_VAR(data->params[0], standout);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Same here @TC72 - even after make distclean, and after deleting and pulling from master from fresh install

There is a patch which fixes everything, I'm now able to build for a native version. Have a look at this thread:
#13533 (comment)

BUT, checking there now there may be a new issue.

Patch for Apple Silicon backported from neovim/neovim#12624 Follow up to Homebrew#68787.

Patch for Apple Silicon backported from neovim/neovim#12624 Follow up to #68787. Closes #70053. Signed-off-by: Sean Molenaar <1484494+SMillerDev@users.noreply.github.com> Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>

jamessan reviewed Jul 11, 2020

View reviewed changes

qvacua mentioned this pull request Jul 14, 2020

Make libvterm compile on arm64 Macs neovim/libvterm#6

Closed

jamessan added the status:blocked-external Needs a third-party / external change or fix label Aug 6, 2020

jamessan linked an issue Aug 22, 2020 that may be closed by this pull request

MacOS 10.15.6 fails to install libvterm #12782

Closed

jamessan mentioned this pull request Aug 22, 2020

MacOS 10.15.6 fails to install libvterm #12782

Closed

jamessan removed the status:blocked-external Needs a third-party / external change or fix label Aug 27, 2020

clason mentioned this pull request Aug 27, 2020

third-party: upgrade libvterm to v0.1.4 #12797

Merged

jamessan removed a link to an issue Aug 28, 2020

MacOS 10.15.6 fails to install libvterm #12782

Closed

justinmk reviewed Aug 30, 2020

View reviewed changes

mikelxc mentioned this pull request Nov 18, 2020

macOS 11 Big Sur compatibility on Apple Silicon Homebrew/brew#7857

Closed

9 tasks

This was referenced Nov 26, 2020

Math.max changes in LuaJIT wbthomason/packer.nvim#103

Closed

SIGKILL when run nvim executable during make with Apple Clang #13399

Closed

jamessan force-pushed the build-arm64-mac branch 3 times, most recently from ab2cb55 to 4d769b5 Compare November 28, 2020 18:47

qvacua and others added 4 commits December 13, 2020 21:03

Use the latest luajit for arm64 Mac compatibility.

12709c4

Do not set pagezero_size and image_base for LuaJIT >= 2.1.0-beta3

27ddaa3

This is properly handled in LuaJIT now and setting causes "Malformed Mach-o file" error when running the resulting binary on arm64 Macs.

third-party: Always set DEPLOYMENT_TARGET when building LuaJIT on macOS

9c5b4c8

LuaJIT build now requires specifying a deployment target, so use the same baseline as our nightly builds. Co-authored-by: Christian Clason <christian.clason@uni-due.de>

jamessan force-pushed the build-arm64-mac branch from eac8ea6 to e8ae3ad Compare December 14, 2020 02:03

jamessan merged commit d6115c9 into neovim:master Dec 14, 2020

jamessan added the maintenance:needs-backport label Dec 14, 2020

TC72 mentioned this pull request Dec 14, 2020

Building Neovim fails on M1 Mac in both Rosetta and Native #13533

Closed

carlocab added a commit to carlocab/homebrew-core that referenced this pull request Feb 10, 2021

neovim: depend on luv, luajit-openresty

c401c87

Patch for Apple Silicon backported from neovim/neovim#12624 Follow up to Homebrew#68787.

carlocab mentioned this pull request Feb 10, 2021

neovim: depend on luv, luajit-openresty Homebrew/homebrew-core#70053

Closed

5 tasks

clason removed the status:needs-backport label Aug 6, 2021

qvacua deleted the build-arm64-mac branch December 6, 2021 20:25

Build for arm64 Macs #12624

Build for arm64 Macs #12624

Conversation

qvacua commented Jul 11, 2020 • edited Loading

Choose a reason for hiding this comment

qvacua Jul 12, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamessan commented Aug 6, 2020

leonerd commented Aug 22, 2020

qvacua commented Aug 22, 2020 • edited Loading

clason commented Aug 26, 2020 • edited Loading

clason commented Aug 26, 2020 • edited Loading

jamessan commented Aug 27, 2020

justinmk Aug 30, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qvacua commented Aug 31, 2020 • edited Loading

mikelxc commented Nov 17, 2020

clason commented Nov 17, 2020

mikelxc commented Nov 17, 2020

clason commented Nov 17, 2020

mikelxc commented Nov 17, 2020

clason commented Nov 17, 2020 • edited Loading

mikelxc commented Nov 17, 2020

qvacua commented Nov 17, 2020 • edited Loading

qvacua commented Nov 17, 2020

qvacua commented Nov 17, 2020

mikelxc commented Nov 18, 2020

stefanpenner commented Nov 24, 2020

menssen commented Nov 24, 2020

jamessan commented Nov 28, 2020

mattnibs commented Dec 11, 2020

jamessan commented Dec 11, 2020

clason commented Dec 11, 2020 • edited Loading

mattnibs commented Dec 13, 2020

TC72 commented Dec 14, 2020 • edited Loading

clason commented Dec 14, 2020

Keating950 commented Dec 14, 2020

TC72 commented Dec 15, 2020

yingzhu146 commented Dec 17, 2020

TC72 commented Dec 17, 2020

qvacua commented Jul 11, 2020 •

edited

Loading

qvacua Jul 12, 2020 •

edited

Loading

qvacua commented Aug 22, 2020 •

edited

Loading

clason commented Aug 26, 2020 •

edited

Loading

clason commented Aug 26, 2020 •

edited

Loading

justinmk Aug 30, 2020 •

edited

Loading

qvacua commented Aug 31, 2020 •

edited

Loading

clason commented Nov 17, 2020 •

edited

Loading

qvacua commented Nov 17, 2020 •

edited

Loading

clason commented Dec 11, 2020 •

edited

Loading

TC72 commented Dec 14, 2020 •

edited

Loading