Conversation
Linker errors |
|
Try disabling https://github.com/Chatterino/chatterino2/blob/master/cmake/FindSol2.cmake#L14. It tells Sol2 that Lua is compiled as C++, while the system one is not. |
This would fix the linking issues, but would cause issues during building instead since we assume lua is built in C++ mode (see https://github.com/Chatterino/chatterino2/blob/master/lib/lua/CMakeLists.txt#L1) so everywhere where we use lua you'd need to make changes. Is vendoring & statically linking sol2/lua problematic for fedora packaging? |
Not sure I get this, is that something that Chatterino requires, outside of what Sol2 does? Will it malfunction with a Lua built as C, if everything is configured properly in Sol2?
Not sure, but I expect so. Vendoring is usually a big no-no for Linux distros. |
This is the solution I would recommend for now. Would it affect anything major on the user side?
Strictly, no. There are packages that bundle lua, but there are a few issues to consider:
This is the key point though. If we use a system built Sol2 configured to link to lua with the C interface (still to be determined that it works), would there be any other lua CXX specific features that it needs? |
|
We rely on the
The users of the Fedora package would not be able to use our plugin system. I don't think this is problematic - it's in alpha right now as we continue to develop it. We don't have any plugins that any sizeable portion of Chatterino users rely on. |
Fair concern there. If a simple catch-all is not possible, it seems it would be more useful to consider enabling CXX support in the lua package itself. Will probably need some help from sol2 devs on that.
Ah, good to know. We would have to have a separate discussion about that. The common topics there are:
We would definitely have to disable it for now pending those discussions. |
In the Fedora package, you mean? Not sure that's possible, since it's currently a C library and doing that would turn it into a C++ library. Unless it's built twice. |
As long as appropriate |
|
26 wrz 2025 09:48:48 Cristian Le ***@***.***>:
* Are there any crucial plugins, and how would we provide plugins as system packages
* Making sure the plugin support works in read-only builds, i.e. chatterino is installed in read-only */usr* but it can check and install writable locations like *$HOME/.local*
Currently there aren't that many plugins, none of them are crucial for the program's operation. Read-only plugins will not work today and would likely need some changes on our side. Chatterino looks in its data folder for plugins, more specifically .local/share/Chatterino/Plugins (up to XDG dirs). Each plugin may save it's data inside of that folder which could be a problem if that directory isnt writable.
I have a temporary list of plugins as a gist: https://gist.github.com/Mm2PL/b5a624dbe872631ce8d9b04529f78ec6
|
Chatterino requires that Lua errors are C++ exceptions, because we rely on the stack unwinding1. If Lua is compiled as C or with longjmp in C++, that won't work. You could probably compile Lua as both C and C++ and merge these, because the intersection of the symbols should be empty. I doubt Fedora would accept this. Footnotes
|
This is what we were referring to about the discussion with @lnicola. I.e. to change the build of Fedora lua to be CXX:
Looking at the current maintainers of lua, I actually think we will have a good chance, but we need to do:
|
|
Thought about this on the train again: When combining C and C++, when building Lua as C++ specifically, the package would depend on the C++ runtime libraries. Of course, for C++, that's needed, but might be unwanted for C. |
|
I think Fedora would need to package two versions of Lua, one built as C and one as C++. They have different ABIs, so you can't switch from C to C++ and still use it in C apps. |
696170d to
eab7e2e
Compare
e3f66b4 to
4ea1a35
Compare
|
IT BUILDS! |
9d075d8 to
d6c252c
Compare
| target_compile_definitions(Sol2 INTERFACE | ||
| SOL_ALL_SAFETIES_ON=1 | ||
| SOL_USING_CXX_LUA=1 | ||
| SOL_USING_CXX_LUA=0 |
There was a problem hiding this comment.
This likely needs to be conditional based on what lua version we detect. But evidently there is some non_trivial source chaanges needed as well based om the test failures that bult lua from scratch (although that one should still be building the cxx version: https://github.com/Chatterino/chatterino2/blob/115428d7f475c75c0ae6c211f0db4c81004ce49b/lib/lua/CMakeLists.txt)
use system lua, for debundling for linux distros