I am attempting to compile Kristall (kristall/BUILDING.md at master · MasterQ32/kristall · GitHub) on Haiku R1/beta2 x86_gcc2 on my trusty Pentium 4. So far, I have discovered that it REALLY does not like variable declarations in C anywhere but at the top of a function (like C of old) - and so was giving me all sorts of parse errors. Well, I may not have gotten much beyond programming simple terminal applications in C, but this was not a tough fix.
But then, once that was fixed for the code I downloaded, header files installed via the built in package manager start throwing all sorts of parse errors such as the list below. My guess is that the cpp compiler is using an older standard - much like the c compiler seems to be doing. Though in the Makefile CXXFLAGS has -std=c++17 set…
Does anyone know any tricks for getting around this issue?
Blockquote /boot/system/develop/headers/x86/QtCore/qglobal.h:390: parse error before {' /boot/system/develop/headers/x86/QtCore/qglobal.h:391: ANSI C++ forbids declaration constexpr’ with no type
/boot/system/develop/headers/x86/QtCore/qglobal.h:391: parse error before Deprecated' /boot/system/develop/headers/x86/QtCore/qglobal.h:477: warning: visibility’ attribute directive ignored
/boot/system/develop/headers/x86/QtCore/qglobal.h:522: parse error before &&' /boot/system/develop/headers/x86/QtCore/qglobal.h:573: parse error before =’
/boot/system/develop/headers/x86/QtCore/qglobal.h:663: syntax error before inline' /boot/system/develop/headers/x86/QtCore/qglobal.h:663: syntax error before &’
/boot/system/develop/headers/x86/QtCore/qglobal.h:665: syntax error before inline' /boot/system/develop/headers/x86/QtCore/qglobal.h:665: syntax error before &’
/boot/system/develop/headers/x86/QtCore/qglobal.h:667: syntax error before inline' /boot/system/develop/headers/x86/QtCore/qglobal.h:667: syntax error before &’
/boot/system/develop/headers/x86/QtCore/qglobal.h: In function void qTerminate()': /boot/system/develop/headers/x86/QtCore/qglobal.h:794: warning: cold’ attribute directive ignored
/boot/system/develop/headers/x86/QtCore/qglobal.h:794: warning: visibility' attribute directive ignored /boot/system/develop/headers/x86/QtCore/qglobal.h:794: parse error before ;’
/boot/system/develop/headers/x86/QtCore/qglobal.h:794: ANSI C++ forbids declaration `noexcept’ with no type
/boot/system/develop/headers/x86/QtCore/qglobal.h:794: confused by earlier errors, bailing out
cpp0: output pipe has been closed
Makefile:6275: recipe for target ‘interactiveview.o’ failed
make: *** [interactiveview.o] Error 1
Well, I think I figured out where I was going wrong. Most of these projects are trying to use the default gcc g++ ln commands, but if I understand it right these are for the gcc2 aspects of the 32bit system for legacy purposes and I want to instead be using gcc-x86 g+±x86 ln-x86 instead for a more modern build system. I have modified one of the make files and this has eliminated the aformentioned issues.
I rather THOUGHT it unlikely that the official headers would be this broken.
You can use the setarch command to switch compiler toolchain. Read the user guide for more info.
This is the clean solution for your problem, you don’t have to edit makefiles and stuff.
I wish people would stop using Haiku like “this is unix, i know this”, and read the guides. Yeah, “aint nobody got time fo dat”. Or use 64 bit, where no such problem exist.
Problem: you should read this, to know about this, but “aint nobody got time fo dat”.
Reading is dead, where is the marketing team to make an ASMR video about this kind of things?
A good advice when building software is to do this in a clean chroot. Haikuporter would achieve this goal elegantly, there are also many Qt5 recipes as examples.
In all seriousness, I didn’t even think to look this as an exercise in porting as it has build directions for Haiku… Apparently I failed to account for the fact that most normal people will be running Haiku (or any O.S.) on a 64 bit CPU.
Thanks for the setarch tip, btw. I’ll have to take that for a spin.
Actually most people I know still run in 32bit because of the binary compatibility with BeOS
Anyway, in most cases you can also use export PATH="/bin/x86:$PATH" which is essentially what setarch does (but you might also have to set some pkg-config variable to point to the x86/ version).
It works, mostly. The patch is on Gerrit and waiting for final review.
However, if you want to use it to run gcc2 apps, the apps and their dependencies must be built for gcc2 secondary architecture. Which would mean yet another architecture to take care of for the packaging infrastructure. I think there were also some compatibility issues and possibly some ideas on how to simplify the implementation of the whole thing.
But it seems not a lot of people are actually interested in making this happen now.
