cmake: change Linux linking to add an explicit lua dependency

[mcepl]

The point of the patch is to avoid relying on indirect/implicit Lua linkage on Linux, because we are building luv against system Lua.

[clason]

What if people want to build against LuaJIT? (Which most people who don't hate performance do.)

[truemedian]

I'm really not sure what situation this is intended to solve.

A Lua module depends on the application embedding/loading it for the lua symbols. If you explicitly link Lua then you will break any application not using the system lua library (including other versions of PUC Lua).

An example of what this would fix would be great because the CI failures seem to reinforce this being a bad idea.

[mcepl]

What if people want to build against LuaJIT? (Which most people who don't hate performance do.)

We built against the LuaJIT as well, I use Neovim, I was porting (unsuccessfully) vis to LuaJIT, so I know what I am talking about. And yes, openSUSE has a symlink from various versions of Lua (and LuaJIT) to /usr/lib64/liblua.so and /usr/lib64/pkgconfig/lua.pc.

However, you are probably also right, that this patch should stay on the distribution level only and it may not be useful here in the upstream repository.

Feel free to close this, if you don’t see any use for you.

[truemedian]

At a bare minimum this change must be applied only when linking system lua (linking our built static/shared lua and system lua is a bug), and should use the found LUA_LIBRARIES instead of a hardcoded library name.

[truemedian]

I'm a bit more confused about this change after a quick look through opensuse's Lua packages, because none of them add -llua or similar. What makes luv special where this is necessary, even at the distribution level?

[mcepl]

The point is that without this patch, I get this:

abuild@mitmanek:~/rpmbuild/BUILD/lua55-luv-1.51.0+1-build/BUILDROOT/usr/lib64/lua/5.5> ldd luv.so 
	linux-vdso.so.1 (0x00007f97cd6e0000)
	libuv.so.1 => /lib64/libuv.so.1 (0x00007f97cd66c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f97cd400000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f97cd6e2000)
abuild@mitmanek:~/rpmbuild/BUILD/lua55-luv-1.51.0+1-build/BUILDROOT/usr/lib64/lua/5.5> 

whereas with this patch I get:

abuild@mitmanek:~/rpmbuild/BUILD/lua55-luv-1.51.0+1-build/BUILDROOT/usr/lib64/lua/5.5> ldd luv.so 
	linux-vdso.so.1 (0x00007fb794d29000)
	libuv.so.1 => /lib64/libuv.so.1 (0x00007fb794cb5000)
	liblua5.5.so.5 => /lib64/liblua5.5.so.5 (0x00007fb794c6e000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fb794a00000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fb794905000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb794d2b000)
abuild@mitmanek:~/rpmbuild/BUILD/lua55-luv-1.51.0+1-build/BUILDROOT/usr/lib64/lua/5.5> 

I don’t like the idea of closing your eyes and hoping for the best in terms of linking Lua library here.

(and I have no idea, what’s the deal with libm).

[bfredl]

That's the intended behavior for lua51 .so modules though. By "closing its eyes" such a module is fully compatible with both liblua5.1 and libluajit , which then becomes a free choice for the application.

[truemedian]

Remember that Luv is a Lua module, it only has meaning if it is loaded into a program that is already using Lua, so Lua symbols can be assumed to be present. If they weren't then no other Lua module would work.

Consider the following scenarios with the status quo, given you have some Application A that was never updated past Lua 5.1 and a system install of Lua 5.5:

Application uses Lua 5.1 and loads Lua 5.1 Luv: works
Application uses LuaJIT loads Lua 5.1 Luv: works
Application uses Lua 5.1 and loads Lua 5.5 Luv: dynamic linker error

Now consider if Luv had been explicitly linked to liblua, and assume we have a dynamic version of liblua for 5.1 somewhere:

Application uses static Lua 5.1 and loads Lua 5.1 Luv: two versions of Lua 5.1 symbols; not an error, just weird
Application uses static LuaJIT and loads Lua 5.1 Luv: two versions of Lua symbols, one for Lua 5.1 and one for LuaJIT; any call into Luv will corrupt the program's Lua state.
Application uses dynamic Lua 5.1 and loads Lua 5.1 Luv: works
Application uses Lua 5.1 and loads Lua 5.5 Luv: two versions of Lua symbols, one for Lua 5.1 and one for Lua 5.5; any call into Luv will corrupt the program's Lua state.

So I once again ask why "closing your eyes and hoping for the best" (which is the status quo for linking modules most everywhere) is bad, when all the alternative does (outside of making the ldd output "nicer") is introduce a failure mode that is otherwise impossible. I also would like to know what makes luv special, such that none of the other Lua packages on OpenSUSE need this same treatment.