Opened 13 months ago
Closed 9 months ago
#68126 closed defect (fixed)
neovim @0.9.1_1: segmentation fault
Description
Error: Failed to build neovim: command execution failed .
:info:build /bin/sh: line 1: 22063 Segmentation fault: 11 ../../../bin/nvim -u NONE -i NONE -n --headless --cmd "set cpo+=+" -S /opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/neovim-0.9.1/src/nvim/po/tojavascript.vim /opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/build/src/nvim/po/nvim.pot /opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/neovim-0.9.1/runtime/optwin.vim :info:build make[2]: *** [runtime/doc/tags] Error 139 :info:build make[2]: *** Waiting for unfinished jobs.... :info:build make[2]: *** [runtime/pack/dist/opt/matchit/doc/tags] Error 139 :info:build make[2]: *** [runtime/pack/dist/opt/vimball/doc/tags] Error 139 :info:build make[2]: *** [src/nvim/po/nvim.pot] Error 139
Attachments (3)
Change History (42)
Changed 13 months ago by dlamija (Muhammed Ramiza)
comment:1 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)
Owner: | changed from raimue@… to raimue |
---|
comment:2 Changed 12 months ago by mseri (Marcello Seri)
The same exact error appears on macos sonoma with 0.9.2, not sure if it is better to note it here or open a separate issue:
:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/runtime && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ ++t\ doc -c quit :info:build /bin/sh: line 1: 2516 Segmentation fault: 11 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ doc -c quit :info:build /bin/sh: line 1: 2521 Segmentation fault: 11 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ doc -c quit :info:build /bin/sh: line 1: 2523 Segmentation fault: 11 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ ++t\ doc -c quit :info:build /bin/sh: line 1: 2513 Segmentation fault: 11 ../../../bin/nvim -u NONE -i NONE -n --headless --cmd "set cpo+=+" -S /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/neovim-0.9.2/src/nvim/po/tojavascript.vim /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/src/nvim/po/nvim.pot /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/neovim-0.9.2/runtime/optwin.vim :info:build make[2]: *** [runtime/pack/dist/opt/matchit/doc/tags] Error 139 [...] :info:build make[2]: *** [runtime/pack/dist/opt/vimball/doc/tags] Error 139
comment:3 Changed 12 months ago by dylanarmstrong (Dylan Armstrong)
I believe the issue is with luv-luajit from some research this morning. If you use the neovim .deps
copy of libluv then it will actually compile correctly. I am looking into this more at the moment.
To duplicate this issue outside of MacPorts:
git clone https://github.com/neovim/neovim.git cd neovim git checkout v0.9.2 make deps mkdir build cd build cmake -DLIBLUV_INCLUDE_DIR=/opt/local/include -DLIBLUV_LIBRARY=/opt/local/lib/libluv.dylib .. make
This should fail with the following
[ 92%] Generating nvim.pot LuaJIT ASSERT lj_api.c:52: index2adr: calling frame is not a C function /bin/sh: line 1: 85788 Abort trap: 6 ../../../bin/nvim -u NONE -i NONE -n --headless --cmd "set cpo+=+" -S /Users/dylan/tmp/nv/neovim/src/nvim/po/tojavascript.vim /Users/dylan/tmp/nv/neovim/build/src/nvim/po/nvim.pot /Users/dylan/tmp/nv/neovim/runtime/optwin.vim make[2]: *** [src/nvim/po/nvim.pot] Error 134 make[1]: *** [src/nvim/po/CMakeFiles/translations.dir/all] Error 2 make: *** [all] Error 2
Changed 12 months ago by frivoal (Florian Rivoal)
Attachment: | main.2.log added |
---|
comment:4 Changed 12 months ago by frivoal (Florian Rivoal)
As far as I can tell, I'm running into the same issue.
comment:5 Changed 12 months ago by helmling
Same issue here on Sonoma. Tried fix mention in #66077 without success.
comment:6 Changed 12 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | l2dy judaew mseri dylanarmstrong frivoal helmling crowell ScarletMetal added |
---|---|
Keywords: | ventura sonoma added |
Summary: | neovim @0.9.1_1 segmentation fault during build on ventura → neovim @0.9.1_1: segmentation fault |
comment:7 Changed 12 months ago by mseri (Marcello Seri)
nvim 0.9.4 recently released also fails in the same way if I update the portfile. I was not able to make it compile, even following the fix mentioned above (on macos sonoma ARM)
comment:8 Changed 11 months ago by psifertex (Jordan)
Cc: | psifertex added |
---|
comment:9 Changed 11 months ago by superobertking (robertking)
Cc: | superobertking added |
---|
comment:11 Changed 11 months ago by jmroot (Joshua Root)
Port: | luv-luajit added |
---|
comment:12 Changed 11 months ago by jonasjonas (Frank Hellenkamp)
Cc: | jonasjonas added |
---|
comment:13 Changed 11 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jpeeler added |
---|
Has duplicate #68551.
comment:14 Changed 11 months ago by jpeeler (Jeff Peeler)
Neovim seems to track the luajit v2.1 branch closely as it's fully up to date at the time of writing this:
https://github.com/LuaJIT/LuaJIT/commit/e826d0c101d750fac8334d71e221c50d8dbe236c
The luajit portfile is using the original 2.1 release, which occurred March 13, 2022.
https://github.com/LuaJIT/LuaJIT/commit/c4fe76d50cda24f3529604448f80ff14754599dd
Since luajit is labeled as a beta, can it just be updated? I'm betting that'll fix the build issue.
comment:15 Changed 11 months ago by jpeeler (Jeff Peeler)
After reading https://github.com/LuaJIT/LuaJIT/issues/563, it seems there are no more releases any more.
comment:16 Changed 11 months ago by tifrueh (Timo Früh)
Cc: | tifrueh added |
---|
comment:17 Changed 11 months ago by nickdowell (Nick Dowell)
Cc: | nickdowell added |
---|
comment:18 Changed 11 months ago by jre21 (Jacob Emmert-Aronson)
Cc: | jre21 added |
---|
comment:19 follow-up: 20 Changed 11 months ago by casr (Chris Rawnsley)
Just noticed this issue after creating: https://github.com/macports/macports-ports/pull/21255
I tested that PR on arm64 Monterey and arm64 Ventura and seems okay. Would someone here who is struggling with this issue be able to report back if that PR makes a difference and what OS & arch you tested it on?
comment:20 Changed 11 months ago by superobertking (robertking)
Replying to casr:
Just noticed this issue after creating: https://github.com/macports/macports-ports/pull/21255
I tested that PR on arm64 Monterey and arm64 Ventura and seems okay. Would someone here who is struggling with this issue be able to report back if that PR makes a difference and what OS & arch you tested it on?
Tested the patch on arm64 Sonoma, but still does not work. Crash log and stack trace remain exactly the same (crashes at libluajit):
(lldb) r Process 79425 launched: '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_relea se_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim' (arm64) Process 79425 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000000027) frame #0: 0x0000000100c9dd00 libluajit-5.1.2.dylib`___lldb_unnamed_symbol511 + 48 libluajit-5.1.2.dylib`___lldb_unnamed_symbol511: -> 0x100c9dd00 <+48>: ldr x10, [x1, #0x28] 0x100c9dd04 <+52>: ldr w11, [x1, #0x34] 0x100c9dd08 <+56>: and x9, x11, x9 0x100c9dd0c <+60>: mov w11, #0x18 Target 0: (nvim) stopped. * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000000027) * frame #0: 0x0000000100c9dd00 libluajit-5.1.2.dylib`___lldb_unnamed_symbol511 + 48 frame #1: 0x0000000100ca5e78 libluajit-5.1.2.dylib`lua_rawget + 40 frame #2: 0x00000001009ac364 libluv.1.dylib`luv_context + 44 frame #3: 0x00000001009ac42c libluv.1.dylib`luv_set_loop + 24 frame #4: 0x00000001001c33a0 nvim`nlua_common_vim_init.llvm.12642962753756758266 + 572 frame #5: 0x00000001001c2188 nvim`nlua_init + 528 frame #6: 0x00000001001ccda8 nvim`main + 5024 frame #7: 0x0000000187505058 dyld`start + 2224
Also tried recompiling luajit port with luajit commit 03c31124cc3b521ef54fe398e10fa55660a5057d, which is the neovim luajit deps version, but still crashes on my arm64 Sonoma.
comment:21 Changed 10 months ago by casr (Chris Rawnsley)
LuaJIT has been bumped to a more recent version https://github.com/macports/macports-ports/pull/21322 which may help
Changed 10 months ago by crowell (Jeffrey Crowell)
Attachment: | main-Nov-12-2023.log added |
---|
log after LuaJIT update
comment:22 Changed 10 months ago by crowell (Jeffrey Crowell)
still fails, uploaded log after updating LuaJIT
comment:23 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | carlocaione added |
---|
Has duplicate #68722.
comment:24 Changed 10 months ago by ebothmann
Cc: | ebothmann added |
---|
comment:25 Changed 10 months ago by samulip (Samuli P)
Cc: | samulip added |
---|
comment:26 Changed 10 months ago by akilman
Cc: | akilman added |
---|
comment:27 Changed 10 months ago by samulip (Samuli P)
FWIW still fails with new luajit 2.1.1700008891
I don't know what to expect of this issue and do not really understand the cause or even the factors leading to the failure.
Building neovim from a Github release 0.9.4 outside macports worked for me.
It was not fully straightforward when there was faffing around with options to make/cmake (-DLIBLUV_INCLUDE_DIR=/opt/local/include -DLIBLUV_LIBRARY=/opt/local/lib/libluv.dylib) but at least there is a working editor for me now
comment:28 Changed 10 months ago by mattaudesse-adi (Matt Audesse)
Cc: | mattaudesse-adi added |
---|
comment:29 Changed 10 months ago by wryfi
Cc: | wryfi added |
---|
comment:30 Changed 10 months ago by wryfi
On an existing machine, upgrading to neovim 0.9.4 worked without a hitch. On my brand new machine, I'm hosed like everyone else. The only obvious difference I see is a couple of older, deactivated luajit ports installed, otherwise the lua packages/environment look identical as far as I can tell.
> port installed | grep lua lua @5.3.6_3 (active) lua-luarocks @3.9.2_0 (active) lua51 @5.1.5_9 (active) lua51-lpeg @1.1.0_0 (active) lua51-mpack @1.0.9_0 (active) lua53 @5.3.6_3 (active) lua53-luarocks @3.9.2_0 (active) luajit @2.1.0-beta3_6 luajit @2.1.1699553127_0 luajit @2.1.1700008891_0 (active) luv-luajit @1.45.0-0_0 (active)
comment:31 Changed 9 months ago by dancorne (Dan Corne)
Cc: | dancorne added |
---|
comment:32 Changed 9 months ago by TheKevJames (Kevin James)
Tried my hand at narrowing down the possible dependency issues here. Following along with [upstream's list](https://github.com/neovim/neovim/blob/v0.9.4/cmake.deps/CMakeLists.txt#L135-L199), I did the following:
- updated unibilium and luajit ports to those specific commit hashes (note: our luajit is actually much *newer* than theirs!)
- bumped libuv and lua51-mpack ports to match the pinned versions
- added a new port lua51-compat53, though I used v0.11 (upstream has some missing rockspec files for v0.9 and v1.0)
Still no dice.
If anyone is interested in continuing this thread, I've got the dependency updates on a branch [here](https://github.com/TheKevJames/macports-ports/branches/all?query=kjames%2F&lastTab=overview). Remaining things I noticed about dependency mismatches but have not yet tested:
- our gettext is 0.21.1, theirs is 0.20.1
- our libiconv is 1.17, theirs is 1.15
- my lua-compat53 portfile was 0.11, theirs is 0.9
- tree-sitter-c, tree-sitter-lua, tree-sitter-query, tree-sitter-vim, and tree-sitter-vimdoc are used upstream but not for us
- the lua-luarocks version we use via the portgroup seems to pull in lua53-luarocks, rather than building via lua51
comment:33 Changed 9 months ago by jpeeler (Jeff Peeler)
I took comment:20 one step further and recompiled luajit in debug mode:
$ lldb --file bin/nvim (lldb) target create "bin/nvim" Current executable set to '/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/build/bin/nvim' (arm64). (lldb) r Process 81514 launched: '/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/build/bin/nvim' (arm64) Process 81514 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000000027) frame #0: 0x0000000100cc5b38 libluajit-5.1.2.dylib`lj_tab_get + 48 libluajit-5.1.2.dylib`lj_tab_get: -> 0x100cc5b38 <+48>: ldr x10, [x1, #0x28] 0x100cc5b3c <+52>: ldr w11, [x1, #0x34] 0x100cc5b40 <+56>: and x9, x11, x9 0x100cc5b44 <+60>: mov w11, #0x18 Target 0: (nvim) stopped.
debug libluajit:
$ nm -U /opt/local/lib/libluajit-5.1.dylib | grep tab_get 0000000000009b08 t _lj_tab_get 0000000000009aa4 t _lj_tab_getinth $ nm -U /opt/local/lib/libluajit-5.1.a | grep tab_get 0000000000001ee8 T _lj_tab_get 0000000000001e84 T _lj_tab_getinth
neovim build from github:
$ nm -U usr/lib/libluajit-5.1.a | grep tab_get 0000000000001028 T _lj_tab_get 0000000000000f88 T _lj_tab_getinth 0000000000000fec T _lj_tab_getstr
I assume if luajit is working as expected the missing symbol above will be resolved. Not sure where to go from here though.
comment:34 follow-up: 36 Changed 9 months ago by echesakov (Egor Chesakov)
I think the issue is due to two conflicting definitions of macro LUA_REGISTRYINDEX
used by luv-luajit
and luajit
ports.
The macro definition seems to change between 5.1 and 5.3 versions of Lua language:
find /opt/local/include -name 'lua\.h' | xargs grep 'define LUA_REGISTRYINDEX' /opt/local/include/lua5.1/lua.h:#define LUA_REGISTRYINDEX (-10000) /opt/local/include/luajit-2.1/lua.h:#define LUA_REGISTRYINDEX (-10000) /opt/local/include/lua5.3/lua.h:#define LUA_REGISTRYINDEX (-LUAI_MAXSTACK - 1000) /opt/local/include/lua.h:#define LUA_REGISTRYINDEX (-LUAI_MAXSTACK - 1000)
When port luv-luajit
and, file luv.c
in particular, is compiled it picks up the definition from /opt/local/include/lua.h
(provided by port lua
).
Note -I/opt/local/include
used in the following command line:
[ 50%] Building C object CMakeFiles/libluv.dir/src/luv.c.o /usr/bin/clang -Dlibluv_EXPORTS -I/opt/local/include -I/opt/local/include/luajit-2.1 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/luv-1.45.0-0/deps/lua-compat-5.3/c-api -pipe -Os -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -mmacosx-version-min=14.0 -fPIC -MD -MT CMakeFiles/libluv.dir/src/luv.c.o -MF CMakeFiles/libluv.dir/src/luv.c.o.d -o CMakeFiles/libluv.dir/src/luv.c.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/luv-1.45.0-0/src/luv.c
By running preprocessor on luv.c
and peeking at the definition of luv_context
function:
cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/build" /usr/bin/clang -Dlibluv_EXPORTS -I/opt/local/include -I/opt/local/include/luajit-2.1 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/luv-1.45.0-0/deps/lua-compat-5.3/c-api -pipe -Os -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -mmacosx-version-min=14.0 -fPIC -MD -MT CMakeFiles/libluv.dir/src/luv.c.o -MF CMakeFiles/libluv.dir/src/luv.c.o.d -o - -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/luv-1.45.0-0/src/luv.c -E | awk '/extern luv_ctx_t\* luv_context\(lua_State\* L\) {/','/lua_type/' extern luv_ctx_t* luv_context(lua_State* L) { luv_ctx_t* ctx; lua_pushstring(L, luv_ctx_key); lua_rawget(L, (-1000000 - 1000)); if ((lua_type(L, (-1)) == 0)) {
it can be seen that the macro expands to (-1000000 - 1000)
.
However, port luajit
(that provides libluajit-5.1.2.dylib
) and ljamalg.c
are compiled against its own version of lua.h
.
By running preprocessor on ljamalg.c
and peeking at the definition of index2adr
function (when the segmentation fault occurs):
cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_luajit/luajit/work/LuaJIT-43d0a19158ceabaa51b0462c1ebc97612b420a2e/src /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_luajit/luajit/work/compwrap/cc/usr/bin/clang -O2 -fomit-frame-pointer -Wall -Os -DLUAJIT_ENABLE_LUA52COMPAT -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U_FORTIFY_SOURCE -DLUA_ROOT=\"/opt/local\" -DLUA_MULTILIB=\"lib\" -fno-stack-protector -DLUAJIT_UNWIND_EXTERNAL -E -o - ljamalg.c | awk '/static TValue \*index2adr\(/,/} else {/' static TValue *index2adr(lua_State *L, int idx) { if (idx > 0) { TValue *o = L->base + (idx - 1); return o < L->top ? o : (&(((global_State *)(void *)(L->glref).ptr64))->nilnode.val); } else if (idx > (-10000)) { ((void)L); return L->top + idx; } else if (idx == (-10002)) { TValue *o = &(((global_State *)(void *)(L->glref).ptr64))->tmptv; settabV(L, o, ((GCtab *)((GCobj *)((L->env)).gcptr64))); return o; } else if (idx == (-10000)) { return (&(((global_State *)(void *)(L->glref).ptr64))->registrytv); } else
it can be seen that the macro expands to (-10000)
.
The segmentation fault occurs
(lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000000027) * frame #0: 0x0000000100c9db38 libluajit-5.1.2.dylib`___lldb_unnamed_symbol507 + 48 frame #1: 0x0000000100ca5ce8 libluajit-5.1.2.dylib`lua_rawget + 40 frame #2: 0x00000001009ac364 libluv.1.dylib`luv_context + 44 frame #3: 0x00000001009ac42c libluv.1.dylib`luv_set_loop + 24 frame #4: 0x00000001001c33a0 nvim`nlua_common_vim_init.llvm.13061164706051272520 + 572 frame #5: 0x00000001001c2188 nvim`nlua_init + 528 frame #6: 0x00000001001ccda8 nvim`main + 5024 frame #7: 0x00000001889150e0 dyld`start + 2360
due to this mismatch since when executing index2adr
(___lldb_unnamed_symbol507
in bt
output) instead of taking else if (idx == LUA_REGISTRYINDEX)
branch the code path go to the else
branch:
static TValue *index2adr(lua_State *L, int idx) { if (idx > 0) { TValue *o = L->base + (idx - 1); return o < L->top ? o : niltv(L); } else if (idx > LUA_REGISTRYINDEX) { lj_checkapi(idx != 0 && -idx <= L->top - L->base, "bad stack slot %d", idx); return L->top + idx; } else if (idx == LUA_GLOBALSINDEX) { TValue *o = &G(L)->tmptv; settabV(L, o, tabref(L->env)); return o; } else if (idx == LUA_REGISTRYINDEX) { return registry(L); } else { GCfunc *fn = curr_func(L); lj_checkapi(fn->c.gct == ~LJ_TFUNC && !isluafunc(fn), "calling frame is not a C function"); if (idx == LUA_ENVIRONINDEX) { TValue *o = &G(L)->tmptv; settabV(L, o, tabref(fn->c.env)); return o; } else { idx = LUA_GLOBALSINDEX - idx; return idx <= fn->c.nupvalues ? &fn->c.upvalue[idx-1] : niltv(L); } } }
By uninstalling lua
port (need to be forced since lua-luarocks
still depends on lua
) and re-installing luv-luajit
port I could make the installation of neovim
succeed.
While looking into this, I also noticed that lua51-lpeg
pulls down both lua51
and lua-luarocks
(which in turns pulls down lua
) and I am not sure if this looks right:
port rdeps lua51-lpeg The following ports are dependencies of lua51-lpeg @1.1.0_0: lua-luarocks lua readline ncurses lua53-luarocks lua53 lua51
Uninstalling lua
is, obviously, not a proper solution here but I wanted to share this in case someone more familiar with MacPorts dependencies would able to pick it up from here.
comment:35 Changed 9 months ago by joshuayoerger (Josh Yoerger)
Cc: | joshuayoerger added |
---|
comment:36 follow-up: 37 Changed 9 months ago by l2dy (Zero King)
Replying to echesakov:
I think the issue is due to two conflicting definitions of macro
LUA_REGISTRYINDEX
used byluv-luajit
andluajit
ports.
If only luv.c
needs to be built against LuaJIT headers, update to luv-luajit @1.45.0-0_1 (_1
means revision 1) and try again.
comment:37 Changed 9 months ago by echesakov (Egor Chesakov)
Replying to l2dy:
If only
luv.c
needs to be built against LuaJIT headers, update to luv-luajit @1.45.0-0_1 (_1
means revision 1) and try again.
This fixed the issue for me. Thank you for updating the port.
comment:38 Changed 9 months ago by superobertking (robertking)
Can confirm it works now! Thanks everyone for the debugging and updating effort!
comment:39 Changed 9 months ago by l2dy (Zero King)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Thanks for confirming the fix!
main.log file with error