Unable to build on Raspberry Pi 4 (aarch64)

[vanfanel]

Hi there, Brad

I just discovered this new Hatari port and I have high hopes on it! Thanks for the work you're putting into this!

However, I am trying to build it on my Pi4 in aarch64 mode, and it fails to do so:

 CC     build/SDL.lo
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.
make[2]: *** [Makefile:290: build/SDL_list.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:362: build/SDL_windowevents.lo] Error 1
make[2]: *** [Makefile:368: build/SDL_rwops.lo] Error 1

I am puzzled that this builds SDL2, since this is supposed to be a Libretro port.
Maybe I am building it wrong? I did:

make full

and since this Pi only has 2GB of RAM, I also tried:

make -j1 full

but I get the same errors. Any advice? Maybe it's early days, but I am so willing to try this and have some Captain Blood fun!

[bbbradsmith]

Hm, gcc: fatal error: Killed signal terminated program cc1 doesn't seem to indicate any direct problem with the code, but rather that gcc itself can't manage for one reason or another. Possibly out of memory?

Since it's failed in the SDL build rather than hatariB's code, I would suggest trying to incrementally continue the SDL build by running its make directly. Not with make full, which is a clean and rebuild, but instead, after the point of failure, do cd SDL/build and then make. Then finally make install if it succeeds. If that completes, then you can just run make in the hatariB directory to build that without restarting the SDL build.

The problem might actually be that in makefile.sdl I added the -j flag directly. Possibly the environment just can't handle building SDL2 in parallel like this? Maybe I should do something to make this optional... though in most cases it's desirable because it will speed up the build considerably.

The "heaviest" part of the compile should actually come a big later when compiling the hatari procedurally generated UAE CPU files, which are pretty huge and take a lot of memory and CPU time to build.

If you're curious why SDL2 is a dependency, there is some information here: DEVELOP.md # SDL2 Usage

[bbbradsmith]

Though, I would also ask, is the aarch64 nightly build usable? rpi64 build here

I don't have an RPi4 to test it with, myself. The Raspberry Pi OS 32-bit build does work for me on an older RPi I have, and the 64-bit build is configured exactly the same except replacing the gnu eabihf compiler with the aarch64 one.

[bbbradsmith]

I've added a MULTITHREAD option to the makfiles. Would you be willing to try the full build again but setting that variable to empty on the command line?

make full MULTITHREAD=

[vanfanel]

@bbbradsmith Yes, nightly build is perfectly usable. CPU usage sits around ~35% (this is on KMS/DRM and Wayland, I don't use old and broken X11 on the Pi4).

Now let's try that new build option. But you shouldn't specify any job number on Makefiles: it's up to the user to specify that via "make -jn"

[vanfanel]

@bbbradsmith Could you please add an option to build against system-installed SDL2?
That way, building would be way faster, and in most cases SDL2 is a very common lib to have installd system-wide in any GNU/Linux system.

[vanfanel]

Oh, it fails anyway:

/root/src/libretro/hatariB/SDL/src/joystick/SDL_joystick.c:1465:13: error: ‘UpdateEventsForDeviceRemoval’ defined but not used [-Werror=unused-function]
 1465 | static void UpdateEventsForDeviceRemoval(int device_index, Uint32 type)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

[bbbradsmith]

Thank you for testing the nightly build. It helps to have verification.

Using a globally installed SDL2 was the initial approach, but it led to various problems. It did work on some platforms, but not on others, and also had a capacity to conflict with RetroArch's SDL2 drivers, if the user was using them. Building them directly was the only way I could manage to get a static version usable on all platforms. I've reduced its configuration to the absolute minimum, at least, but yes it becomes overhead for the full build.

If you wish, you can still provide your own by overriding the path variables: SDL2_INCLUDE, SDL2_LIB and SDL2_LINK.

The failure is strange, though, because I don't know how -Werror=unused-function gets added for your build. On all 6 nightly builds there is -Wunused-function indicating a warning there, but not an error.

Did SDL's config enable this on your platform, or is there something in your environment providing that?

[bbbradsmith]

I've added --enable-werror=no to makefile.sdl. Does that manage to correct it?

[vanfanel]

@bbbradsmith In the end this small SDL error was my fault. I was doing:
CFLAGS="-march=native -mtune=native -fomit-frame-pointer" CXXFLAGS="-march=native -mtune=native -fomit-frame-pointer" make full MULTITHREAD=

After removing my custom CFLAGS and CXXFLAGS, it builds.

Next I will do a build using system-installed SDL2 as per your instructions.

[vanfanel]

@bbbradsmith How should I pass my own custom CFLAGS? I don't see any env var for extra flags on the Makefile.

[bbbradsmith]

CFLAGS is just an append in the makefile, so it should just use and add to whatever you provide.

For make full it is not propagated to the recursive make of makefile.sdl, but you could either use export to make CFLAGS continue to its subprocesses, or instead use make -f makefile.sdl directly with your own CFLAGS for SDL.

[vanfanel]

What I am trying is to simply pass custom CFLAGS to the Hatari core, ideally both the core and SDL should receive the ones I pass.
But they seem to break compilation somehow.

[vanfanel]

@bbbradsmith I am doing this to try to build against system SDL2:
make full MULTITHREAD= SDL2_INCLUDE=/usr/local/include/SDL2 SDL2_LIB=/usr/local/lib SDL2_LINK=/usr/local/lib

..but the build system is still trying to build SDL2. Any advices, please?

[vanfanel]

@bbbradsmith Ah, removing "full" works. So, to build against system-installed SDL2:
make MULTITHREAD= SDL2_INCLUDE=/usr/local/include/SDL2 SDL2_LIB=/usr/local/lib SDL2_LINK=/usr/local/lib/libSDL2.a

[bbbradsmith]

The full target is specifically to rebuild everything, including the two dependent libraries (with a clean before starting). You can use the default target to skip that and just build hatariB.

Also, the SDL2_LIB should end with libSDL2.a, and SDL2_LINK is intended to call sdl2-config though I don't know where that ends up in the global install... as a substitute you can maybe just use the path to libSDL2.a instead (sdl2-config is linker flags and inclusion of the library... i'm not sure how important the linker flags are).