<div dir="ltr">Hello,<div><br></div><div>I appreciate your reply and the time you took to write it. :)</div><div><br></div><div>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."</div><div><br></div><div>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.</div><div><br></div><div>Anyway, there is already documentation on cross compiling with distcc on <a href="http://docs.slackware.com">docs.slackware.com</a> 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.</div><div><br></div><div>Best regards,</div><div>Brent</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 16, 2021 at 1:02 PM B Watson <<a href="mailto:yalhcru@gmail.com">yalhcru@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This email got longer than expected. Please bear with me...<br>
<br>
On 3/16/21, Brent Earl <<a href="mailto:brent@exitstatusone.com" target="_blank">brent@exitstatusone.com</a>> wrote:<br>
> gcc -DLUA_USE_LINUX -c -o liolib.o liolib.c<br>
> In file included from /usr/include/bits/errno.h:26,<br>
> from /usr/include/errno.h:28,<br>
> from lauxlib.c:9:<br>
> /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or<br>
> directory<br>
> 1 | #include <asm/errno.h><br>
> | ^~~~~~~~~~~~~<br>
<br>
Generally that error is caused by a missing symlink. /usr/include/asm<br>
is supposed to be a symlink to asm-<ARCH>, e.g. asm-x86. The symlink<br>
is part of the kernel-headers package, as is the asm-<ARCH> dir.<br>
<br>
> +elif [ "$ARCH" = "armv7hl" ]; then<br>
> + SLKCFLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16"<br>
> + LIBDIRSUFFIX=""<br>
> +elif [ "$ARCH" = "aarch64" ]; then<br>
> + SLKCFLAGS="-O2 -fPIC"<br>
> + LIBDIRSUFFIX="64"<br>
<br>
I know what these CFLAGS do, and I agree they're useful (and<br>
LIBDIRSUFFIX=64 is necessary) for arm/arm64... but I don't see how<br>
they fix the error you were having above (missing asm/errno.h would<br>
still be missing). There's more to this story.<br>
<br>
> This brought on a larger concern I have about SBo as a whole. Will ARM and<br>
> soon ARM64 continue to be unsupported by SBo? Both are official ports of<br>
> Slackware and should have at least some basic support. More and more<br>
> systems will use these architectures due to the increased hardware<br>
> performance. ARM is not an isolated issue anymore and it stunts the ports<br>
> if SBo is too difficult to use on the platforms.<br>
<br>
The main reason SBo builds aren't tested on arm/arm64 is that most<br>
of us apparently don't own or use arm hardware. At least, I don't,<br>
and I very rarely see discussion of arm stuff on the mailing list or<br>
IRC channel.<br>
<br>
Secondary reason is the extra work and time involved: a maintainer<br>
is already expected to test everything on two platforms (x86 and<br>
x86_64). Adding 2 more platforms doubles the test-build time (or worse<br>
than doubles, because most of us would be using qemu or some other<br>
ARM emulator). The SBo admins and maintainers are unpaid volunteers,<br>
and you may have noticed that we don't have a long list of policies<br>
and rules...<br>
<br>
I'd accept patches for my builds that fix ARM-specific problems, but<br>
I'm never going to buy a fast ARM box just to do test compiles on. The<br>
traditional way to work around that would be to use a fast x86_64 box<br>
and cross-compile the ARM stuff... but SlackBuilds aren't generally<br>
set up for cross compiles (try it sometime).<br>
<br>
I know raspberry pi machines are cheap... but looking at their specs,<br>
they're also pretty underpowered as far as compiling lots of software<br>
goes.<br>
<br>
All the above looks very negative... so here are some positive<br>
suggestions:<br>
<br>
We can and should add your SLKCFLAGS stuff to the template. When 15.0<br>
gets released, we'll be doing a lot of 'housekeeping' stuff to the SBo<br>
repo to get it ready for 15. One of those things might be adding your<br>
SLKCFLAGS to all existing SlackBuilds (at least the ones that ain't<br>
"noarch").<br>
<br>
Someone, or a team of someones, could volunteer to be the "ARM<br>
maintainer(s)". This would involve testing stuff, actively looking<br>
for problems, and sending patches to fix them. Whoever does this would<br>
ideally follow the weekly update emails and test-build everything that<br>
got upgraded.<br>
<br>
There's a way to set up distccd to work with a cross-compiler. This<br>
would let people run builds on a little raspberry pi and offload<br>
the actual compilation to one or more bigger/faster machines. Unlike<br>
regular cross compiles, this is 'transparent'. I've done this, ages<br>
ago (though not for ARM). I could write a HOWTO specifically for SBo<br>
and ARM, so people could set up "compile servers" to speed things up.<br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
</blockquote></div>