[opensuse-factory] Curious case of publicly used Lua library ... static library or public one?
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. What would you suggest? Any precedents for either solution? Thank you for kindly kicking me in the right direction, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 To err is human, to purr feline.
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)
On Friday 2019-06-21 10:51, Matěj Cepl wrote:
neovim decided in its latest versions (..) to [use] luv Lua library and link to it.
Linking is a technically easier case than dlopen, so why not.
It bundles its own version of the library, but I think it is necessary to unbundle and use openSUSE package for it.
I see no openSUSE:Factory/*luv*, so can't use that (yet). It is not always obvious at first whether a bundled component is actually a tailored copy (it happens in "doomsday" with assimp for example).
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? 4. Use neovim's bundled library.
When packages bundle components, they usually link to them (rather than a system copy). So this is already the default case. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-06-22, 21:49 GMT, you wrote:
It bundles its own version of the library, but I think it is necessary to unbundle and use openSUSE package for it.
I see no openSUSE:Factory/*luv*, so can't use that (yet).
It is still in https://build.opensuse.org/package/show/home:mcepl:branches:devel:languages:... Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If we rise from prayer better persons, our prayers have been answered. -- a Jewish prayer book -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
İsmail Dönmez -
Jan Engelhardt -
Matěj Cepl