Manjaro/Arch: add_requires("lua", { system = true }) links both liblua and liblua++

[rws-git]

Hello
I came across what I beleive is either a misconfiguration on my side or an incorrect behaviour of xmake. I seek for help, please.

On Manjaro (and probably Arch), the system Lua package has 2 shared libraries: liblua.so and liblua++.so, presumably with mangled/demangled names for C/C++ linkage.

When xmake compiles a simple project with add_requires("lua", { system = true }), it links the resulting executable or library against both lua libs.
In certain scenarios this causes SEGFAULT crashes of the app when the code uses luaL_error() function. My guess is that the longjmp instruction that happens underneath, goes to the address space of the wrong library.

I have set up a minimal reproducible scenario here: https://github.com/rws-git/xmake-luapp. The app has an executable and a lib. The scenario is as follows:

• executable starts and calls luaL_dofile("luapp.lua")
• the script does lpp = require('xmake-luapp') and pcall(function() lpp.dummy(3) end)
• dummy() functions calls luaL_error
• app crashes, although the raised error must have been caught by pcall
  And don't mind, that the files have .c extension. Originally, I encountered same issue with a C++ project, so I need to use g++.

Below are some screenshots of the problem. First, the xmake build and run:

Second, manual compilation with only one system Lua lib linkage and successful run:

[rws-git]

I have found a solution which seems to work fine for my case and that is using add_syslinks("lua") instead of add_requires + add_packages.
But I am still curious why the aforementioned approach links 2 libraries instead of one.

UPD: add_syslinks is not the cure. It works on Manjaro, but fails on Ubuntu/Debian/Void linux. Manjaro puts header files of the current Lua version into standard /usr/include. I think, Ubuntu and others use versioning in paths where they place headers.