On 12/16/18 11:43 PM, Daurnimator wrote: > On Tue, 11 Dec 2018 at 18:50, Eli Schwartz <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
