Closed rbanffy closed 1 month ago
Got two transcriptions for armv6 (which fails) and armv7 (which succeeds). Also, attached the diff between them.
config-armv6.txt config-armv7.txt armv6-armv7-diff.txt
In both cases, the external modules are placed under an 'arm' folder inside the respective 'lib'.
Odd, because Raspberry Pi Zero (at least used to) works, with Hercules-Helper. But I haven't connected one up to test this PR yet. (family issues)
Bill
I'm working under Docker Desktop's QEMU emulation. From inside arch
reports "armv7", but the config output suggest armv6. I'm running a test with QEMU_CPU=arm1176 (which will ignore the RPi's FPU) but I won't have results for some time. The failure could be related to the emulation. I'll fire up a build on one of my Zeros to check. Should take longer than under emulation though.
OK, I've fired up a Pi Zero. Trying it out now...
This is a GCC problem ...
As you can see ...
"More and more packages in Debian need manual addition of libatomic on some 32bit vintage architectures (armv5/m68k/mips/powerpc/sh4) due to this, which is a pain."
Works for me on a Raspberry Pi Zero W with Hercules-Helper.
This is a GCC problem ...
Looks like the configuration under armv6 (and other "relics") need to add libatomic deliberately then. Thanks.
I'll dig into the autoconf tooling. The Debian patches can be a good starting point for that.
Works for me on a Raspberry Pi Zero W with Hercules-Helper.
Is Hercules Helper adding libatomic to the build configuration?
Feature detection seems to be off - from running a compile (following the Dockerfile mentioned, which works on everything I tried EXCEPT armv6l):
checking if '__atomic' intrinsics are available... yes
checking if C11 atomics are available... yes
checking what 'ATOMIC_BOOL_LOCK_FREE's value is... 1
checking what 'ATOMIC_CHAR_LOCK_FREE's value is... 1
checking what 'ATOMIC_CHAR16_T_LOCK_FREE's value is... 1
checking what 'ATOMIC_CHAR32_T_LOCK_FREE's value is... 1
checking what 'ATOMIC_WCHAR_T_LOCK_FREE's value is... 1
checking what 'ATOMIC_SHORT_LOCK_FREE's value is... 1
checking what 'ATOMIC_INT_LOCK_FREE's value is... 1
checking what 'ATOMIC_LONG_LOCK_FREE's value is... 1
checking what 'ATOMIC_LLONG_LOCK_FREE's value is... 1
checking what 'ATOMIC_POINTER_LOCK_FREE's value is... 1
This shouldn't happen in a Pi Zero. Unless this detection comes from the libatomic1 that's installed in the machine.
Since @wrljet reports Hercules-Helper suceeds on the same platform, I guess it's patching the build system in some way that fixes whatever is causing this.
I haven't looked yet. I've been away all day.
Opened this ticket on the wrong repo. The codebase I'm compiling is https://github.com/SDL-Hercules-390/hyperion/
Ahh, I missed that, too. I was testing with SDL.
Your log file config-armv6.txt
shows:
#9 3946.2 checking build system type... armv7l-unknown-linux-gnueabi
#9 3952.6 checking host system type... arm-unknown-linux-gnueabihf
#9 3953.3 checking target system type... arm-unknown-none
Mentions armv7l
Bill
Compiling on ARMv6 fails with the error below. The same process (getting external dependencies, building them with CMake, copying artifacts to the expected folders under the hyperion tree, then compiling Hyperion itself) suceeds in amd64, arm64, armv7, ppc64le, and s390x.
The full process is documented in https://github.com/rbanffy/hercules-base/blob/main/Dockerfile#L42-L131.
Full log is available at nice n 19 docker build.txt
The process is fully repeatable with
docker build -t hercules-base:latest-armv6 --platform=linux/arm/v6 --progress=plain .
running from a checkout of https://github.com/rbanffy/hercules-base/