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? Once again: for anyone wishing to provide a different version of the lua library, interpreter, and/or pkg-config file should presumably modify the same names in all three as a set. This does not detract from the logic of supporting pkg-config via a pkg-config file meant to describe the project itself.
So some extra context may be required here. Lua needs to be used by two different types of code: 1. code that embeds lua 2. lua libraries written in C
For most unix systems (this is *not* true on windows):
Things in category 1 include the `lua` executable itself, as well as applications like mame, powerdns, vlc, etc. If they link against lua statically, then they should expose lua C symbols via e.g. -Wl,--export-dynamic If they link against lua dynamically then they are fine.
I don't get how that argues against pkg-config... That sounds like the job of the application to use, that they know they absolutely need to expose all symbols just in case and don't want to mess with linker scripts for upstream symbols. What's the cost of doing that in your embedded application that links against liblua and finds a system-provided dynamic lib? The failure to optimize your symbol table, when you didn't expect to be able to dynlink at all? But let's imagine instead, lua devs who support static only, and wish to support pkg-config discovery. This is lua.pc, no versions Name: Lua Version: 5.3.5 Description: An Extensible Extension Language Cflags: -I${includedir} Libs: -L${libdir} -Wl,--export-dynamic -llua -lm Applications which desire to embed lua can link using: CFLAGS += $(shell pkg-config --cflags lua) LDLIBS += $(shell pkg-config --libs lua) Applications which wish to build modules for lua can skip the LDLIBS since they don't link to lua, and coincidentally also don't need to --export-dynamic. Downstream distros which patch lua to build shared libraries are also responsible to optimize their ecosystem symbol tables by patching out -Wl,--export-dynamic Downstream distros that provide both dynamic and static libs can instead move it to Libs.private, and pkg-config will only emit it when using: pkg-config --static --libs lua ... 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.
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 -- Eli Schwartz Bug Wrangler and Trusted User