On 21 Jun 10:51, Matěj Cepl wrote:
Hello,
all Lua extension modules written in C are modules in the libtool terminology opened by dlopen and so they are stored in %{_libdir}/lua/%{lua_version}/ private directory (e.g., /usr/lib64/lua/5.1/lpeg.so) and they are called only by Lua interpreter, which knows to look for them there. Now, however, neovim decided in its latest versions (not released yet, just in the master branch on GitHub) to luv Lua library and link to it. It bundles its own version of the library, but I think it is necessary to unbundle and use openSUSE package for it.
Now, I have the question, what should I do? I guess, I can:
1. Persuade somehow Neovim to link against private module. That’s probably a nonsense, right?
2. Introduce whole concept of public Lua libraries (including a snippet in /etc/ld.so.conf.d/ and all that jazz) just because of neovim? (I can easily persuade luv CMake scripts to generate public library, if necessary) Moreover, I would have to deal somehow with necessity to have two versions of a library, because we maintain two (incompatible) versions of Lua (5.1 and 5.3), so something like %{_libdir}/lua-public/%{lua_version}/?).
3. Use static library, which seems like the least disruptive for the system, but it seems rather strongly discouraged in
https://en.opensuse.org/openSUSE:Shared_library_packaging_policy
4. Use neovim's bundled library.
Maybe, 5. Build neovim with -Wl,-rpath %{_libdir}/lua/%{lua_version} and then it'll find the private library ismail -- SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)