-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Neovim cannot load native Lua modules that are not linked with LuaJIT #22328
Comments
That definitely is a quandry. We aren't doing anything out of the ordinary for the build options. Our Neovim is compiled with We do not package Footnotes
|
@TomJo2000 Thanks for your quick reply! I've set up a minimal reproduction here, feel free to try it out. This problem was initially discovered by trying to build native modules for a neovim plugin and use it on Termux (corresponding issue). It was later reported to the mlua repo but similarly the author didn't know what to do with it. I've tried on a few different combinations of runtimes and platforms and finally the problem seems to only occur on Neovim + Termux. I don't know enough about Lua to write a module in C as proposed by the mlua author, but personally I don't think mlua is the faulty one (since it runs normally with |
My best guess is this is some sort of linker issue. // nm -uC ./target/debug/libreprod.so
U __cxa_atexit
U __cxa_finalize
U __errno
U __register_atfork
U __sF
U abort
U calloc
U clock_gettime
U close
U dl_iterate_phdr
U fflush
U fprintf
U free
U fstat
U fwrite
U getcwd
U getenv
U getpid
U lseek64
U luaL_callmeta
U luaL_error
U luaL_getmetafield
U luaL_ref
U lua_checkstack
U lua_close
U lua_concat
U lua_createtable
U lua_error
U lua_gc
U lua_getallocf
U lua_getinfo
U lua_getmetatable
U lua_getstack
// There's the symbol from the initial bug report
U lua_gettop
U lua_insert
U lua_isnumber
U lua_isstring
U lua_newthread
U lua_newuserdata
U lua_next
U lua_pcall
U lua_pushboolean
U lua_pushcclosure
U lua_pushfstring
U lua_pushinteger
U lua_pushlightuserdata
U lua_pushlstring
U lua_pushnil
U lua_pushnumber
U lua_pushthread
U lua_pushvalue
U lua_rawequal
U lua_rawget
U lua_rawset
U lua_remove
U lua_replace
U lua_setmetatable
U lua_settable
U lua_settop
U lua_toboolean
U lua_tolstring
U lua_tonumber
U lua_topointer
U lua_tothread
U lua_touserdata
U lua_type
U lua_typename
U lua_xmove
U malloc
U memcmp
U memcpy
U memmove
U memset
U mmap
U munmap
U open
U posix_memalign
U pthread_getspecific
U pthread_key_create
U pthread_key_delete
U pthread_rwlock_rdlock
U pthread_rwlock_unlock
U pthread_rwlock_wrlock
U pthread_setspecific
U read
U readlink
U realloc
U realpath
U sched_yield
U stat
U strerror_r
U strlen
U syscall
U write
U writev I did also validate the module against Lua 5.1, which did work as expected. I'll see if I can get any useful information out of |
Does
make things work for you? |
As expected, yes it does. |
I think this is a difference between Android and proper Linux linker/loaders
I think there are two workarounds:
I think this is really in the category of "lua expects Linux behavior, Android deviates from it". |
Okay, good to know that I'm not just missing something very obvious here. I guess the questions that remain are;
These two aren't mutually exclusive. It's probably not even fair to call this a bug in |
I'm afraid I don't know which other packages include shared libraries for use with lua, but it would be a good idea to find one and check whether there's a
I don't think it's a bug in the neovim package.
I think the issue can be worked around in |
This issue originates from android/ndk#201, also stated in https://github.com/termux/termux-packages/wiki/Common-porting-problems. This not really specific to Termux but to Android OS in general.
|
So it's a bug in neither package and the symbols are still missing. |
Is there anything we can do to manually "expose" the symbols? Oh wow that is one to one the issue we're having here... Note
|
Solution is simple: force link it with library providing necessary symbols. This issue affects native extensions for all scripting languages (that's why for python often suggested to specify |
Welp, guess you'll need to link the library or use @pipcet's Is there any specific rationale for why the Android linker limits symbol visibility like this? |
Rust/Lua module for Android can be forcibly linked with LuaJIT by compiling with:
or setting corresponding options in |
Ok fine, even this exact problem has been reported before (#6383) and I've only found it through the ndk issue. Thanks for your effort, maybe this can be closed as duplicate now. I'm glad that there are several workarounds to this problem and I'll try to find which one is feasible for cross compiling in a CI (as requested in Saghen/blink.cmp#145) |
I'd like to ask if it's a good idea (or even permitted) to download the libluajit.so artifact from Termux in CI? If not, what should be the best practice to link the library with it? |
https://github.com/mlua-rs/mlua/blob/4891a6ac10e152625073335ad0703a6e68aa36fc/mlua-sys/build/main_inner.rs#L33-L34 |
Yes, that's the intended behavior of So I'd like to know if I choose to link the module to luajit instead (in any of the ways suggested above), is there a good way to build it in CI environment? Do I need to get a copy of |
You can build by cloning this repo, |
Yes, that's why I'm generally against distributing binaries. Maybe it makes most sense to set rustflags in cargo config and don't provide CI so that people can build on their own devices? It still needs |
There is https://github.com/termux-user-repository/tur/tree/master/tur/rustc-nightly Install via |
So I think the best available workaround is to make |
This dance is required to make Android's dlopen() implementation resolve symbols exported by libluajit.so to Lua modules. Fixes termux#22328
This dance is required to make Android's dlopen() implementation resolve symbols exported by libluajit.so to Lua modules. Fixes termux#22328
This is required to make Android's dlopen() implementation resolve symbols exported by libluajit.so to Lua modules. Co-authored-by: Pip Cet <[email protected]> closes termux#22328
This dance is required to make Android's dlopen() implementation resolve symbols exported by libluajit.so to Lua modules. Fixes termux#22328
Problem description
Neovim is unable to load lua modules created with mlua if the module is not specifically linked with LuaJIT.
require
-ing the module throws an error saying that dlopen cannot locatelua_gettop
(or some other lua symbols).This doesn't happen when the same code is run with
luajit
instead ofnvim
.What steps will reproduce the bug?
"luajit"
)cargo build
cd
into./target/debug
ln -s lib*.so my_module.so
nvim --clean --cmd "lua require('my_module')"
What is the expected behavior?
The module is loaded and the function is accessible.
If the library is instead built with
RUSTFLAGS="-C link-args=-lluajit" cargo build
it works as expected, but this is not required on any other platforms and it makes cross compiling very difficult.System information
The text was updated successfully, but these errors were encountered: