Riesi

Okey so all issues that libxml2 wanted to fix are on their latest upstream now. Only remaining fix is for the function pointer that changed. They suggested that 0ad should fix this. They also linked a commit from WebKit fixing it. https://github.com/WebKit/WebKit/commit/1bad176b2496579d760852c80cff3ad9fb7c3a4b I used this patch as a base for the same issue on the 0ad side. Casting the function pointer to `xmlStructuredErrorFunc` would have also worked, but it would be less clean in my opinion. Error: ../../../source/ps/XML/RelaxNG.cpp:162:50: error: invalid conversion from ‘void (*)(void*, xmlErrorPtr)’ {aka ‘void (*)(void*, _xmlError*)’} to ‘xmlStructuredErrorFunc’ {aka ‘void (*)(void*, const _xmlError*)’} [-fpermissive] 162 | xmlRelaxNGSetValidStructuredErrors(ctxt, &relaxNGErrorHandler, NULL); | ^~~~~~~~~~~~~~~~~~~~ | | | void (*)(void*, xmlErrorPtr) {aka void (*)(void*, _xmlError*)} ../../../source/ps/XML/Xeromyces.cpp:59:41: error: invalid conversion from ‘void (*)(void*, xmlErrorPtr)’ {aka ‘void (*)(void*, _xmlError*)’} to ‘xmlStructuredErrorFunc’ {aka ‘void (*)(void*, const _xmlError*)’} [-fpermissive] 59 | xmlSetStructuredErrorFunc(NULL, &errorHandler); | ^~~~~~~~~~~~~ | | | void (*)(void*, xmlErrorPtr) {aka void (*)(void*, _xmlError*)} libxml2_fix.patch

Upstream libxml2 fixed some regressions already! But there are still a few build issues. I commented in the existing issue with the currently still existing build issues. https://gitlab.gnome.org/GNOME/libxml2/-/issues/642 I still dont get verification emails from 0ad phabricator

Downgrading to Arch's libxml2 2.11.4-1 made it work. So this is clearly a libxml2 issue. I guess all Linux build issues of 0AD are fixed then with phosit's patch merged.

I am using the one from my distro's (Arch) package manager, yes. libxml2 2.12.1-1 Looking at the PKGBUILD file they base it on this commit: git+https://gitlab.gnome.org/GNOME/libxml2.git#commit=f4ac9926a463ecb628f73049e4fd7ecced8fb7cf

Something really is fishy about libxml2 with all these errors popping up all over the place.

I think I reproduced their errors: First error: FCollada/FUtils/FUXmlDocument.cpp: In constructor ‘FUXmlDocument::FUXmlDocument(FUFileManager*, const fchar*, bool)’: FCollada/FUtils/FUXmlDocument.cpp:39:39: error: ‘xmlParseMemory’ was not declared in this scope 39 | xmlDocument = xmlParseMemory((const char*) fileData, (int)fileLength); | ^~~~~~~~~~~~~~ FCollada/FUtils/FUXmlDocument.cpp: In constructor ‘FUXmlDocument::FUXmlDocument(const char*, size_t)’: FCollada/FUtils/FUXmlDocument.cpp:67:23: error: ‘xmlParseMemory’ was not declared in this scope 67 | xmlDocument = xmlParseMemory(data, (int)length); | ^~~~~~~~~~~~~~ In file included from FCollada/FMath/FMath.h:44, from FCollada/FUtils/FUtils.h:81: Second error: FColladaPlugins/FArchiveXML/FArchiveXML.cpp: In member function ‘virtual bool FArchiveXML::EndExport(fm::vector<unsigned char>&)’: FColladaPlugins/FArchiveXML/FArchiveXML.cpp:515:34: error: ‘xmlAllocOutputBuffer’ was not declared in this scope; did you mean ‘xmlOutputBuffer’? 515 | xmlOutputBufferPtr buf = xmlAllocOutputBuffer(NULL); | ^~~~~~~~~~~~~~~~~~~~ | xmlOutputBuffer FColladaPlugins/FArchiveXML/FArchiveXML.cpp:519:24: error: ‘xmlOutputBufferGetSize’ was not declared in this scope; did you mean ‘xmlOutputBufferPtr’? 519 | outData.resize(xmlOutputBufferGetSize(buf) * sizeof(xmlChar)); | ^~~~~~~~~~~~~~~~~~~~~~ | xmlOutputBufferPtr FColladaPlugins/FArchiveXML/FArchiveXML.cpp:520:33: error: ‘xmlOutputBufferGetContent’ was not declared in this scope; did you mean ‘xmlOutputBufferPtr’? 520 | memcpy(outData.begin(), xmlOutputBufferGetContent(buf), outData.size()); | ^~~~~~~~~~~~~~~~~~~~~~~~~ | xmlOutputBufferPtr FColladaPlugins/FArchiveXML/FArchiveXML.cpp:526:9: error: ‘xmlOutputBufferClose’ was not declared in this scope; did you mean ‘xmlOutputBufferPtr’? 526 | xmlOutputBufferClose(buf); | ^~~~~~~~~~~~~~~~~~~~ | xmlOutputBufferPtr In file included from FCollada/FCDocument/FCDocument.h:27, from FColladaPlugins/FArchiveXML/FArchiveXML.h:21: Fixing the first error is simple: diff --git a/libraries/source/fcollada/src/FCollada/FUtils/FUXmlDocument.cpp b/libraries/source/fcollada/src/FCollada/FUtils/FUXmlDocument.cpp index 5349249a87..2acf93006e 100644 --- a/libraries/source/fcollada/src/FCollada/FUtils/FUXmlDocument.cpp +++ b/libraries/source/fcollada/src/FCollada/FUtils/FUXmlDocument.cpp @@ -13,6 +13,8 @@ #include "FUFile.h" #include "FCDocument/FCDocument.h" +#include <libxml/parser.h> + #define MAX_FILE_SIZE 10240000 // // FUXmlDocument The second is hard because the file has mixed line endings with a few lines not being CRLF but instead LF and `patch` not being happy when applying. Imho the file should be fixed to either pure CRLF or LF. Following patch needs to be applied in binary mode to not break on a "different line endings" error: diff --git a/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.cpp b/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.cpp index af67478960..99b64b9925 100644 --- a/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.cpp +++ b/libraries/source/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.cpp @@ -77,7 +77,7 @@ #include "FCDocument/FCDVersion.h" #include "FUtils/FUXmlDocument.h" - +#include <libxml/xmlIO.h> // // Constants //

I also encounter new errors now: ../../../source/collada/XMLFix.cpp: In function ‘void FixBrokenXML(const char*, const char**, size_t*)’: ../../../source/collada/XMLFix.cpp:169:25: error: ‘xmlParseMemory’ was not declared in this scope 169 | xmlDocPtr doc = xmlParseMemory(text, (int)textSize); | ^~~~~~~~~~~~~~ make[1]: *** [Collada.make:162: obj/Collada_Release/XMLFix.o] Error 1 make[1]: *** Waiting for unfinished jobs.... ../../../source/collada/CommonConvert.cpp: In constructor ‘FColladaErrorHandler::FColladaErrorHandler(std::string&)’: ../../../source/collada/CommonConvert.cpp:59:9: error: ‘xmlSetGenericErrorFunc’ was not declared in this scope 59 | xmlSetGenericErrorFunc(&xmlErrors, &errorHandler); | ^~~~~~~~~~~~~~~~~~~~~~ ../../../source/collada/CommonConvert.cpp: In destructor ‘FColladaErrorHandler::~FColladaErrorHandler()’: ../../../source/collada/CommonConvert.cpp:68:9: error: ‘xmlSetGenericErrorFunc’ was not declared in this scope 68 | xmlSetGenericErrorFunc(NULL, NULL); | ^~~~~~~~~~~~~~~~~~~~~~ make[1]: *** [Collada.make:138: obj/Collada_Release/CommonConvert.o] Error 1 Which can be fixed by: diff --git a/source/collada/XMLFix.cpp b/source/collada/XMLFix.cpp index 2f1d67770e..39b8b08855 100644 --- a/source/collada/XMLFix.cpp +++ b/source/collada/XMLFix.cpp @@ -23,6 +23,8 @@ #include "FUtils/FUXmlParser.h" +#include <libxml/parser.h> + /* Things that are fixed here: diff --git a/source/collada/CommonConvert.cpp b/source/collada/CommonConvert.cpp index 391fcf47f6..2a57cea395 100644 --- a/source/collada/CommonConvert.cpp +++ b/source/collada/CommonConvert.cpp @@ -30,6 +30,7 @@ #include <cassert> #include <algorithm> +#include <libxml/xmlerror.h> void require_(int line, bool value, const char* type, const char* message) {

Yeah its better to get some of the issues fixed than to wait to repro the others too. Thanks again!

Thank you for making the upstream patch! I am fine with "Riesi" as the credit. Could the "invalid conversion" errors be from a newer GCC version (13.2.1)? As for "#include <libxml/parser.h>" I am not sure why I get the error about missing declarations and you seemingly don't. It would be great if all errors would be fixed upstream, but I am ok carrying fixes locally for a while too. Until a better solution is found. Thanks again!

$ inxi -SMGxx System: Host: REalArch Kernel: 6.6.3-arch1-1 arch: x86_64 bits: 64 compiler: gcc 13.2.1 Desktop: KDE Plasma v: 5 tk: Qt v: 5.15.11 wm: i3 dm: startx Distro: Arch Linux

Sure! Ok it was not -pendantic but just the compiler telling me that its related to -permissive. build_errors.txt

Hmm seems like I dont even get mails from the bug tracker anymore. Maybe the wildfiregames email server has issues in general.

Hello! I am regularly playing 0ad with a friend. We decided to always play the latest Windows autobuild. This means I have to compile that revision for Linux. And lately a few build issues due to missing includes or --pendantic not being happy happened. Attached is a patch to fix the current build issues. Hopefully someone can apply this fix upstream. I tried to figure out how to contribute, but Phabricator doesn't send me the verification email for my account. Hopefully I can make an account when the transition away from SVN and Phabricator is complete. I was reading in the git transition thread that Gitea and CI is coming together, so a commit breaking Linux compilation should be less likely after that. Kind regards, Riesi linux_build_fixes.patch

Found the reason. It was a crash at launch due to an outdated version or missing SPIRV mod. Kinda annoying. I guess there are plans to include the shaders when 0.27 finally hits. Okey then I see my journey with Github Actions as concluded for now. :) Nightly/Weekly builds for everyone would be very cool! Yeah I understand that the workforce is already limited, so new features takes time. Still the quality and amount of content of 0ad is really great! Thanks for the answers.

Hello! I wanted to setup Github actions, so that I can can get Windows builds without touching the OS. Main reason being that a friend had issues with the latest automated build and I wanted to try fixing things maybe. I initially tried building 0ad in my VM and after that I hacked together a Github action for it. Due Github maybe limiting the total data size of artifacts, I also made an action that auto deletes older artifacts. I am not sure if this is really needed. You can find the repo here: https://github.com/Riesi/0ad_builder For anyone curious about the code: https://github.com/0ad/0ad/compare/master...Riesi:0ad_builder:master Built artifact of the binaries/system folder with the EXEs stripped from the PDB files here (only 15min of build time!): https://github.com/Riesi/0ad_builder/actions/runs/6468547522 Now my main question is, if such a Github action would be wanted or useful for upstream 0ad? I am not sure if only the "binaries/system" folder needs to be dropped into a recent git clone, but bundling more stuff into the artifact would be easy. For what its worth one could maybe even create a script that pulls the latest git master and inserts the latest artifact into it. Additionally maybe one could setup a build process for Linux/MacOS. Kind regards, Riesi