Refactor game build configuration and build dll as subproject

[illwieckz]

Refactor game build configuration to reuse the same code in parent build or subproject build and mutualize code between vm type build.

Also build hardened dll game with sub cmake to use different compilation flags.

Obsoletes:

• cmake: make possible to enable LTO when compiling dll games #1481

See on game side:

• Refactor game build configuration and build dll as subproject Unvanquished/Unvanquished#3270

[slipher]

Please no 😭. Having stuff built in a sub-invocation makes everything suck. For example:

• When building with Ninja you don't get any progress messages.
• Can't build targets individually. I often use this ability when working on something in the sgame because of the cgame taking a lot longer to build (due to rmlui).

[illwieckz]

Now it only builds the dll game in a subproject when HARDENING is ON, it builds it as a usual otherwise.

I refactored a lot the code, also fixed some mistakes with nexe (the nacl target strings was parsed also with saigo, but there is none). Actually the build* functions I've done may be refactored too but I postpone that.

[illwieckz]

Actually the build* functions I've done may be refactored too but I postpone that.

Rethinking about it, I discovered it was easier than what I thought, so I did it.

[illwieckz]

I'm happy with that deep refactor. It will also make implementing Wasm easier.

I split the changes in two commits:

• The deep refactor making it easy to build something as subproject without copy-pasting a ton of boiler-plate.
• A small commit building the dll as subproject when USE_HARDENED is enabled, but building the dll as usual otherwise.

The same code now being reused for the various builds, it is even more robust than ever.

[slipher]

While we were discussing this in IRC the other day, I found a link that claims you can used the "PIC" flag on everything and it will work (unlike the "PIE" flag on everything which breaks dynamic libs). https://mropert.github.io/2018/02/02/pic_pie_sanitizers/

[illwieckz]

I now renamed the PR:

Refactor game build configuration to reuse the same code in parent build or subproject build and mutualize code between vm type build

The ability to build an hardened dll with PIC while hardened exe is PIE by using a subproject for hardened dll is actually a demonstration of how the new CMake code is now reusable and provides a framework for such things, instead of relying on lengthy boiler-plate copy-paste. Adding another subproject for a toolchain like WASI would just reuse the same framework.

That framework may also be used for other occurrences of either building a game code in a subproject or in parent project directly, like building a wasm game with a native engine (subproject), or a wasm game with a wasm engine (parent project).

[slipher]

Building DLL in a subproject with PIC seems worse than building both engine and DLL with PIC, assuming the latter is possible.

Adding another subproject for a toolchain like WASI would just reuse the same framework.

I'm having trouble following this since we already have NaCl toolchains with the exact same structure that a WebAssembly one would need.

[illwieckz]

I just got that error while trying to run an armhf engine with an armhf dll game on Linux:

Warn: Error during initialization: VM: Failed to load shared library VM cgame-native-dll.so:
cgame-native-dll.so: unexpected reloc type 0x03 

According to this comment:

Relocation type 3 is R_ARM_REL32 which is a static relocation not allowed in shared objects. How did you create the shared lib? Make sure you compile all the code going into it with -fPIC.

I understand I get that error because the dynamic library is linked with code that was meant for the engine executable.

[illwieckz]

Well, that's probably an Arm variant of:

/usr/bin/ld: daemon/libs/freetype/libfreetype.a(truetype.c.o):
 warning: relocation against `TT_RunIns' in read-only section `.text'
/usr/bin/ld: daemon/libs/freetype/libfreetype.a(truetype.c.o):
 relocation R_X86_64_PC32 against symbol `TT_RunIns' can not be used when making a shared object;
 recompile with -fPIC

[illwieckz]

I reproduce those kind of errors on both amd64 and arm64 even when I disable hardening, I'm fed up of working around those bugs with random CMake options.

[slipher]

While we were discussing this in IRC the other day, I found a link that claims you can used the "PIC" flag on everything and it will work (unlike the "PIE" flag on everything which breaks dynamic libs). https://mropert.github.io/2018/02/02/pic_pie_sanitizers/

Was there any real drawback of building all code with -fPIC? I can't remember.

[illwieckz]

Obsoleted by:

• cmake: refactor game build configuration to reuse the same code in parent build or subproject build and mutualize code between vm type build #1555
• cmake: use -fPIC when compiling all object files, but only -pie when linking executables #1556