[Slackbuilds-users] Cannot build lua, many other scripts on arm and arm64

[B Watson]

This email got longer than expected. Please bear with me...

On 3/16/21, Brent Earl <brent at exitstatusone.com> wrote:
> gcc -DLUA_USE_LINUX   -c -o liolib.o liolib.c
> In file included from /usr/include/bits/errno.h:26,
>                  from /usr/include/errno.h:28,
>                  from lauxlib.c:9:
> /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or
> directory
>     1 | #include <asm/errno.h>
>       |          ^~~~~~~~~~~~~

Generally that error is caused by a missing symlink. /usr/include/asm
is supposed to be a symlink to asm-<ARCH>, e.g. asm-x86. The symlink
is part of the kernel-headers package, as is the asm-<ARCH> dir.

> +elif [ "$ARCH" = "armv7hl" ]; then
> +  SLKCFLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16"
> +  LIBDIRSUFFIX=""
> +elif [ "$ARCH" = "aarch64" ]; then
> +  SLKCFLAGS="-O2 -fPIC"
> +  LIBDIRSUFFIX="64"

I know what these CFLAGS do, and I agree they're useful (and
LIBDIRSUFFIX=64 is necessary) for arm/arm64... but I don't see how
they fix the error you were having above (missing asm/errno.h would
still be missing). There's more to this story.

> This brought on a larger concern I have about SBo as a whole.  Will ARM and
> soon ARM64 continue to be unsupported by SBo?  Both are official ports of
> Slackware and should have at least some basic support.  More and more
> systems will use these architectures due to the increased hardware
> performance.  ARM is not an isolated issue anymore and it stunts the ports
> if SBo is too difficult to use on the platforms.

The main reason SBo builds aren't tested on arm/arm64 is that most
of us apparently don't own or use arm hardware. At least, I don't,
and I very rarely see discussion of arm stuff on the mailing list or
IRC channel.

Secondary reason is the extra work and time involved: a maintainer
is already expected to test everything on two platforms (x86 and
x86_64). Adding 2 more platforms doubles the test-build time (or worse
than doubles, because most of us would be using qemu or some other
ARM emulator). The SBo admins and maintainers are unpaid volunteers,
and you may have noticed that we don't have a long list of policies
and rules...

I'd accept patches for my builds that fix ARM-specific problems, but
I'm never going to buy a fast ARM box just to do test compiles on. The
traditional way to work around that would be to use a fast x86_64 box
and cross-compile the ARM stuff... but SlackBuilds aren't generally
set up for cross compiles (try it sometime).

I know raspberry pi machines are cheap... but looking at their specs,
they're also pretty underpowered as far as compiling lots of software
goes.

All the above looks very negative... so here are some positive
suggestions:

We can and should add your SLKCFLAGS stuff to the template. When 15.0
gets released, we'll be doing a lot of 'housekeeping' stuff to the SBo
repo to get it ready for 15. One of those things might be adding your
SLKCFLAGS to all existing SlackBuilds (at least the ones that ain't
"noarch").

Someone, or a team of someones, could volunteer to be the "ARM
maintainer(s)". This would involve testing stuff, actively looking
for problems, and sending patches to fix them. Whoever does this would
ideally follow the weekly update emails and test-build everything that
got upgraded.

There's a way to set up distccd to work with a cross-compiler. This
would let people run builds on a little raspberry pi and offload
the actual compilation to one or more bigger/faster machines. Unlike
regular cross compiles, this is 'transparent'. I've done this, ages
ago (though not for ARM). I could write a HOWTO specifically for SBo
and ARM, so people could set up "compile servers" to speed things up.