Control: tags -1 - patch

After submitting the aforementioned merge request (and another one with
other improvements including CI pipelines), I see now that the patch
removal was intentional: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032533

On 2023-03-08 at 14:44, Jackson wrote:

This patchfile undermines that Lua can be built as C++ to manage unwinding exceptions; according to the date, it has been in the Debian Lua repository for
over seven years. For example, future releases of MAME (package: mame) will break using USE_SYSTEM_LUA_LIB if this fallacy not resolved, since they link their own copy.

I'm not sure what this bug report is trying to say or how `extern "C"`
(simply preventing C++ name mangling) could undermine or break anything
in what is really a C library (C symbol names, just compiled to throw
and catch C++ exceptions). (Does MAME link against both a system C++
Lua and its own C Lua copy?) But whatever.

And from https://salsa.debian.org/lua-team/lua5.4/-/merge_requests/4#note_444235

With this we found that the current c++ library in sid is probably broken (and unused since nobody complained so far)

Yes, it is broken, but I'm trying to use it for the upcoming
wesnoth-1.18 which can now use a system copy of Lua (after over a month
of work toward that goal):
https://github.com/wesnoth/wesnoth/pull/8234

Since lua5.4 was promoted to Ubuntu main in 23.10 and Wesnoth now uses
Lua without modifications, the goal is for wesnoth-1.18 to use the
lua5.4 package supported in Ubuntu main (instead of Wesnoth's embedded
code copy stuck in universe) before the Ubuntu Noble Debian Import
Freeze on 2024-02-29. So I hope this can somehow be fixed well before
then (wesnoth-1.18 still has to go through NEW before that date).

I found that the reason it is broken with `extern "C"` removed and name mangling newly enabled is that debian/patches/0001-build-system.patch
links using the export map debian/version-script which doesn't list
the C++ symbols. Adding the C++ symbols to debian/version-script and debian/liblua5.4-0.symbols as I attempted in the updated merge requests
would fix this, however C++ symbol names are architecture-specific.
So we'll have to either collect arch-specific names with `(arch=foo)`
tags[1] (by making buildds fail for a while[2]) or switch to using
shlibs[3]. The wiki recommends shlibs: "For C++ libraries it is often
better not to ship symbols files."[1] Sounds good, especially since
going through multiple uploads and waiting for buildds to fail would
take time. Except switching to shlibs means losing the version
information noting that the mangled symbols didn't exist before now,
so users who install a package (that uses the C++ library's mangled
symbols) without updating liblua5.4-0 will see run-time linker errors.
To solve that, we need to also bump the C++ library's SONAME version
(which is appropriate anyway, given that the ABI completely changed).
So unless you disagree (or beat me to it), I'll work on switching to
shlibs and bumping the SONAME version.

Restoring `extern "C"` would avoid all this mess and keep the previous unmangled symbols in case anyone was using the C++ library before now.
But the previous bug report claims that this breaks something (so let's
break everything else instead).

[1]: https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries
[2]: https://www.eyrie.org/~eagle/journal/2012-01/008.html
[3]: https://www.eyrie.org/~eagle/journal/2012-02/001.html
--
Patrick "P. J." McDermott: http://www.pehjota.net/
Lead Developer, ProteanOS: http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)