Alpine CI build failure for armv7

[sodface]

The Alpine package had armv7 disabled due to CI build failures. The issue seems to be that arch reports armv8l. I'm not really sure if this should be fixed somehow on the Alpine end instead or if this patch is any good, but it helped:

--- a/make/system.mk.orig
+++ b/make/system.mk
@@ -66,6 +66,10 @@
   override ARCHITECTURE   = arm32
   ARCHITECTURE_FAMILY     = arm32
   ARCHITECTURE_CFLAGS    := -march=armv7-a -marm
+else ifeq ($(patsubst armv8l%,armv7,$(BUILD_ARCH)),armv7)
+  override ARCHITECTURE   = arm32
+  ARCHITECTURE_FAMILY     = arm32
+  ARCHITECTURE_CFLAGS    := -march=armv7-a -marm
 else ifeq ($(patsubst armv8%,armv8,$(BUILD_ARCH)),armv8)
   override ARCHITECTURE   = aarch64
   ARCHITECTURE_FAMILY     = aarch64

[sadko4u]

You always can override the architecture by overriding the ARCHITECTURE parameter in the make config run. For example:

make config ARCHITECTURE=armv7

I think the detection of armv8 is incorrect and should detect the system as 32-bit instead of 64-bit.

[sodface]

Thanks. I don't have any feedback yet from the Alpine team so I'll see if I get some and update this issue if so. Supposedly:

The armv8l mode in uname means your kernel is built to run on an ARMv8 chip in its 32-bit mode.

So it could be that Alpine is using a 64bit capable CPU in 32bit mode as the armv7 builder.

[sodface]

Some excerpts from Alpine's IRC logs:

2020-07-12 07:57:05 <russkel> why on earth does this keep failing
2020-07-12 08:04:17 <russkel> wait the armv7 builder returns armv8l ?
2020-07-12 08:04:26 <russkel> mind blown
2020-07-12 08:53:17 <ikke> russkel: the builders run on aarch64 in 32-bits mode. Curious is though that we specify armv7l in lxc, but `arch` return armv8l
2020-07-12 08:53:27 <ikke> While on the host it returns aarch64
2020-07-12 08:59:12 <russkel> is that a bug or some weirdness?
2020-07-12 08:59:31 <russkel> I have amended my patch to add armv8l in any case
2020-07-12 09:00:10 <ikke> I don't know
2020-07-12 10:30:11 <clandmeter> ikke: that's normaal
2020-07-12 10:30:28 <clandmeter> Normal on the right keyboard
2020-07-12 10:31:05 <clandmeter> armv8l is aarch64 in 32bit mode
2020-07-12 10:31:24 <ikke> Right

2021-08-07 16:05:45 <ikke> so we run on armv8l, but userspace is armv6l or armv7l
2021-08-07 16:06:16 <nmeum> interesting
2021-08-07 16:13:23 <ikke> similar with x86 btw
2021-08-07 16:14:14 <nmeum> but on x86 uname -m seems to return i386, doesn't it?
2021-08-07 16:15:32 <ikke> yes, there is not separate x86_64 arch apparently :)
2021-08-07 16:15:40 <ikke> x86_64 32-bits arch

Maybe one one of the Alpine devs can suggest a way to account for it in the APKBUILD, or just keep the above patch applied downstream.

[sadko4u]

I think your patch should affect the next condition block after your changes which exactly looks for the armv8 substring in the processor architecture given by the uname -m.

[sadko4u]

I'll fix the build scripts for all subprojects now.

[sadko4u]

I think this should be pertty enough to repair your build:
d00882e

Please verify

[sodface]

CI pipeline:
https://gitlab.alpinelinux.org/sodface/aports/-/pipelines/145085

aarch64 and armv7 look ok but armhf is detected as armv7 so I'm not sure that's going to work even though the package builds. Still investigating.

[sodface]

Could you review the comments by Alpine dev Alice:

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/41772

[sadko4u]

it's not (should be v6), but the build (should?) fail if that was the actual case, since gcc/binutils cannot link the armv6 target as they only support the one they're built for (armv7)

I think you should explicitly add ARCHITECTURE=armv6 for the make config call. The makefiles know absolutely nothing about what target architecture should be used for compiling the source code except the uname -m returns. If there is some way to determine it, then we can discuss the workaround.

if there's a verbose way to get the actual build invocation (g++ -O -I .. .. ) that would have the actual information; some debug logging from the makefile is not a source of truth and hence not useful to debug what is being passed where

Yes, there is VERBOSE=1 flag which can be passed to the make call. For more information and flags, you can issue make help.

overall that entire makefile does not make sense in this specific case (why do you ever have to specify march unless you are cross compiling? the default toolchain one is what you want..), so if you want a quick fix just entirely delete that section (but not things like -msse -mfpu and so on), all the flags are redundant for a default target

You can reset the ARCHITECTURE_CFLAGS parameters by passing the empty value to make config. That will disable settings of architecture-dependent compiler flags in the build configuration.

[sadko4u]

Also note that LSP Plugins require ARM instruction set, not Thumb nor Thumb2, so probably you will be required to pass the -marm flag as ARCHITECTURE_CFLAGS.

[sodface]

Thanks for the support on this and sorry for the churn. We added this to the APKBUILD file:

# GitLab CI and builders run armhf/armv7 as 32-bit arches on aarch64.
# Thus, we cannot rely on the uname -m output on these platforms.
case "$CTARGET_ARCH" in
armhf) export ARCHITECTURE=armv6l ;;
armv7) export ARCHITECTURE=armv7l ;;
esac

It's passing CI and has been merged so I believe this issue can be closed?

[sadko4u]

Since the problem has affected some changes to the source code, I'll close this issue after 1.2.4 release.

[sadko4u]

Also, short hotice: after you have specified the PREFIX variable in make config, it seems that you don't need to specify it in further make calls like this:

https://gitlab.alpinelinux.org/alpine/aports/-/blob/6fc9b097a8ff8a8ca92d46408c54285f9f0005f3/testing/lsp-plugins/APKBUILD#L41

[sodface]

@sadko4u I'm sorry, I missed your comment about the PREFIX variable. Thanks for pointing this out, I'll see if I can get it fixed.

[sadko4u]

Available in 1.2.4!