hercules-390 / hyperion

Hercules 390
Other
246 stars 69 forks source link

Failure to compile under ARMv6 #304

Closed rbanffy closed 1 month ago

rbanffy commented 1 month ago

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.

#9 15825.0   CC       hettape.lo
#9 15867.7   CC       omatape.lo
#9 15917.8   CC       scsitape.lo
#9 15972.0   CC       scsiutil.lo
#9 16007.1   CCLD     libhdt3420_not_mod.la
#9 16029.9   CCLD     cckdcdsk
#9 16053.7 /usr/bin/ld: ./.libs/libhercu.so: undefined reference to `__atomic_compare_exchange_8'
#9 16053.8 collect2: error: ld returned 1 exit status
#9 16053.8 make[2]: *** [Makefile:2259: cckdcdsk] Error 1
#9 16053.9 make[2]: Leaving directory '/home/hercules/hyperion'
#9 16054.3 make[1]: *** [Makefile:2681: all-recursive] Error 1
#9 16054.4 make[1]: Leaving directory '/home/hercules/hyperion'
#9 16054.6 make: *** [Makefile:2002: all] Error 2

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/

rbanffy commented 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'.

wrljet commented 1 month ago

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

rbanffy commented 1 month ago

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.

wrljet commented 1 month ago

OK, I've fired up a Pi Zero. Trying it out now...

joemonk64 commented 1 month ago

This is a GCC problem ...

image

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."

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

wrljet commented 1 month ago

Works for me on a Raspberry Pi Zero W with Hercules-Helper.

rbanffy commented 1 month ago

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.

rbanffy commented 1 month ago

Works for me on a Raspberry Pi Zero W with Hercules-Helper.

Is Hercules Helper adding libatomic to the build configuration?

rbanffy commented 1 month ago

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.

wrljet commented 1 month ago

I haven't looked yet. I've been away all day.

rbanffy commented 1 month ago

Opened this ticket on the wrong repo. The codebase I'm compiling is https://github.com/SDL-Hercules-390/hyperion/

wrljet commented 1 month ago

Ahh, I missed that, too. I was testing with SDL.

wrljet commented 1 month ago

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