tdauth
Issues Building & Running on PureOS Byzantium (based on Debian Bullseye)
I tried to compile this project on PureOS which is a Debian-based distribution (similar to Ubuntu) but I encountered a conflict between the suggested libogre-1.9-dev package, and the C++20 support on GCC 10.
As far as I could tell (and it's possible I was reading this incorrectly), the OGRE headers have the following compile error within their header:
error: ‘const_pointer’ in ‘class std::allocator<void>’ does not name a type
which is located in the included file
/usr/include/OGRE/OgreMemorySTLAllocator.h
After monkeying around with this for some time, I found that:
- Support for the "void" allocator was deprecated in C++17, so I'm guessing it was removed in C++20 but only sorta kinda maybe
- Installing GCC/G++ 9 and replacing my system install with it (update alternatives - in place of my default GCC/G++ 10), then going into the CMake settings of this project and replacing
-std=c++20with-std=c++2acause the world to compile in a state where the allocator header compile error does not show, and then the project compiles successfully.
It is late and I am about to sleep, so my understandings of these topics might be incorrect, but this is how it appeared to be for now.
It seemed that after the above configuration issues, the wc3editor application crashed on Patch 1.22, Patch 1.26, and Patch 1.29 data provided to the popup, however. Cause is unclear to me and I have exhausted my time available for testing this for the time being:
Got temporary file "/tmp/WorldEditStrings.txt.gUrXKJ"
Removing temporary file: "/tmp/WorldEditStrings.txt.gUrXKJ"
terminate called after throwing an instance of 'std::exception'
what(): std::exception
Thread 1 "wc3editor" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff4472537 in __GI_abort () at abort.c:79
#2 0x00007ffff46d87ec in () at /lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff46e3966 in () at /lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff46e39d1 in () at /lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff46e3c65 in () at /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff6e41dc6 in wc3lib::editor::MetaData::load() (this=0x5555563ff100) at /home/retera/repos/wc3lib/wc3lib/src/editor/metadata.cpp:476
#7 0x00007ffff6e887e7 in wc3lib::editor::WarcraftIIIShared::refreshWorldEditorStrings(QWidget*, QUrl const&) (this=0x555555813670, window=0x0, url=...) at /home/retera/repos/wc3lib/wc3lib/src/editor/warcraftiiishared.cpp:95
#8 0x00007ffff6e88087 in wc3lib::editor::WarcraftIIIShared::refreshDefaultFiles(QWidget*) (this=0x555555813670, window=0x0) at /home/retera/repos/wc3lib/wc3lib/src/editor/warcraftiiishared.cpp:41
#9 0x00007ffff6e32d03 in wc3lib::editor::Editor::configure(QWidget*, QString const&, QString const&) (this=0x7fffffffd770, parent=0x0, organization=..., applicationName=...) at /home/retera/repos/wc3lib/wc3lib/src/editor/editor.cpp:160
#10 0x00007ffff6e33052 in wc3lib::editor::Editor::configure(QWidget*) (this=0x7fffffffd770, parent=0x0) at /home/retera/repos/wc3lib/wc3lib/src/editor/editor.cpp:182
#11 0x00005555555909a0 in main(int, char**) (argc=1, argv=0x7fffffffdf98) at /home/retera/repos/wc3lib/wc3lib/src/editor/app/wc3editor.cpp:52
I believe I may have tracked the inability for wc3lib to build and run on my configuration to a regression in the boost libraries. According to the following:
https://stackoverflow.com/questions/67587485/why-does-boostspiritunicodechar-no-longer-work-with-utf-8-char-strings
https://github.com/boostorg/spirit/issues/678
... it appears that after boost version 1.72 it cannot parse UTF8 strings or whatever. After I jumped through some hoops to get the src/editor/test/metadata test working (it appears to have some out-of-order memory reference undefined behavior that can be trivially fixed by reordering stack variables) the test then fails on my machine because it fails to parse the strings. When I dumped out the contents of the WorldEditStrings.txt file that remains unparsed after the boost spirit qi phrase_parse(...) thing returns, the unparsed portion of the file begins at the location of the first non-ASCII character:
WESTRING_RACE_DEMON=Dämon
Namely, when parsing the above key-value pair, the parse stops after WESTRING_RACE_DEMON=D.
Would I be correct in understanding that the issue, then, is boost itself -- and that building and running wc3lib on this machine is not going to work?
Edit: Seems that "PureOS Byzantium" (probably mirrors Debian Bullseye) is on boost version 1.74.
Hm I haven't tested wc3lib for some time since it is unfinished anyway. You can use/compile it maybe when disabling the EDITOR option in CMake. Didn't know about the Boost stuff. You should maybe try the latest Boost version or suggest a fix in the code. Note that wc3lib's editor module only does some basic stuff which is not really that useful. The only useful stuff is probably some APIs to read the formats and modify object data etc.
I have commented on the GitHub issue of Boost Spirit and I am trying to fix this issue since I have to use tools again. It should still work without German strings and English only.
Implemented a simple custom TXT parser and not using Boost.Spirit anymore due to this issue.