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

[Brent Earl]

Hello,

I appreciate your reply and the time you took to write it.  :)

The build completes when LIBDIRSUFFIX is set to "64".  I should have
clarified about that, apologies.  The patch is meant more as a way to sort
of fix builds for aarch64 in SBo in general.  Arm32 works with most
SlackBuilds, sometimes with other modifications.  But aarch64 will not work
if the _else_ portion of the _if_ statement is missing at the end.  In the
case of lua, the SlackBuild didn't check for the aarch64 architecture.  It
skips it because it doesn't know about it.  The script continues, assumes
$( uname -m ) and doesn't set any SLCKFLAGS for aarch64.  The kernel
headers are installed on the system and are not the problem.  The problem
is that the script assumes "libaarch64" instead of "lib64."

I hadn't planned on setting up a build infrastructure to test build all of
SBo for Slackware ARM.  I wasn't looking to start the huge project of
porting all of SBo to arm or aarch64.

Anyway, there is already documentation on cross compiling with distcc on
docs.slackware.com for ARM.  All that would be required is integrating a
tool (sbopkg as an example) into a cross compiler for SBo.  Maybe, modify
Stuart Winter's "x-toolchain" from the "slackwarearm-devtools" directory to
do so.  To clarify further, an expensive ARM build server is not
necessary.  Off-load to other devices on the network with distcc.  Anyone
with a large SBo build for x86/x64 (Qt, I am looking at you) should already
be doing this anyway.

Best regards,
Brent


On Tue, Mar 16, 2021 at 1:02 PM B Watson <yalhcru at gmail.com> wrote:

> 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.
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20210316/f2c211d3/attachment-0001.htm>