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/
