On 12/16/18 11:43 PM, Daurnimator wrote:
On Tue, 11 Dec 2018 at 18:50, Eli Schwartz <eschwartz@archlinux.org> wrote:
On 12/11/18 6:19 PM, Daurnimator wrote:
If lua does not officially compile a C++ version, it is the job of Debian to both provide their own pkg-config files, and modify lua to build using C++.
Lua supports either compiling with longjmp or C++ based exceptions. See "Error-recovery functions" near https://www.lua.org/source/5.3/ldo.c.html#errorstatus
Okay, that's fine. So how does this work, then, and why does it need a separate pkg-config file? Is it just a matter of renaming liblua.a to liblua-c++.a to prevent filename clashes and thereby permit parallel installation? So... why is this any different from renaming the versioned libraries?
It is not essentially a different ABI? liblua.a uses longjmp for error handling, libluac++.a.so uses C++ exceptions. If you want to specifically link against e.g. the C++ one, what should a lua-using-project use?
Downstream distros which patch lua to build shared libraries are also responsible to optimize their ecosystem symbol tables by patching out -Wl,--export-dynamic
This is where upstream turns around and says "if everyone is patching it, why should we ship it at all?"
If everyone is patching it, why should lua ship a *Makefile*? But I didn't say anyone should patch it. Micro-optimizations for things that work either way aren't really relevant. What is relevant is that: - people building their own unpatched liblua.a can use it without modifications - people who build distro-patched lua can *also* use it without modifications - people who build several historically versioned copies of their distro-patched lua have a canonical file with rigidly defined linker flags, which *also* can be used without modifications due to, if I read the Makefile correctly, defining LUA_A with a versioned name. This is already needing to be defined at install time due to the installation target directory. - people who want to both build a distro-patched shared library for lua, *and* micro-optimize their symbol table that works fine either way, can do whatever they want. ... You're right though, having a configuration system is way too controversial if I cannot even convince you.
In all cases, the pkg-config file by design should work as-is, with the assumption that it describes the project which is compiled using make && sudo make install. It's a madness game to even pretend to also support the modifications which people make to the build system.
upstream lua has historically shipped with a "please create your own build system". For many years the recommended compilation instructions were "give the .c files to your compiler of choice and hit build" Such instructions are relatively timeless e.g. https://youtu.be/-jvLY5pUwic
Now I think we here agree that this isn't the best way forward, but the upstream audience is diverse and can take time to convince.
Things in category 2 include libraries such as lua-filesystem. They expose an entrypoint of luaopen_mylibname, and use the lua C api. These should *not* link against liblua, and need to rely on symbols provided by the host application.
However note that both categories of code need to find the lua headers.
That's fine, it makes it even more convenient to reserve --libs for the exclusive use of -Wl,--export-dynamic
I just know that someone would reply to me with something like the following if I proposed this, so I may as well see what your response is:
package config's --libs output is meant for use with LDLIBS. Flags for the linker should *not* be passed in LDLIBS and should only be passed in LDFLAGS
My response would be: If you take a closer look at the manual page for pkg-config, it actually says the exact opposite, defining "--libs" as "linker flags". In fact, there are even three dedicated *subvariants* to get, depending on your highly customized needs, --libs-only-L --libs-only-l --libs-only-other This is clearly a case of libs-only-other. -- Eli Schwartz Bug Wrangler and Trusted User