Will arm get a slackbuild site like the x86 Slackware? I've found that many Slackbuilds work fine on arm, while some need minor changes. If we find a slackbuild that can be made to work fine on arm should we notify the maintainer or if there a larger project like the x86-current updates?

I'm not sure what you refer to about 'x86-current updates', but the best thing to do would be to ask on the SlackBuilds development mailing list if there might be a protocol for tagging particular build scripts as being verified _not_ working on ARM (and/or soon Slackware AArch64) (should no fixes be available).
Given that in most cases I rarely make any ARM or AArch64 changes to the x86 SlackBuilds, I'm going to assert that it may be a similar finding with the scripts at SBo.

This: https://www.linuxquestions.org/quest...ls-4175561999/

Where Ponce has a copy of all of the Slackbuilds and makes updates for any that won't build against -current (for x86 and x86_64) so when -current becomes 15 all the Slackbuilds will be ready. I start with those Slackbuilds since is at -current and then make any small changed needed.

I had one simply say "arm isn't supported", a couple trying to use x64 in the path, and a few that just needed -fPIC passed in because they were written like this:
and needed to have an other elif for arm added like this:
hmm, now that I think about it what does the libdir for 64 bit arm look like, I haven't installed any yet.

OpenCSG for example fails with
so I added the above to it. Technically it would work if I added the -fPIC to the else but I was trying to do it proper and define arm as an option.

I'll hunt down the mailing list.

That's a task of no insignificant magnitude! Just to give an idea of how long it may take to build the packages: for the recent ARM world build, there were ~930 packages (excluding KDE) building on a quad core Orange Pi Plus2E/4GB RAM using 4 parallel jobs with distcc, and it took about 3 days to build. That's just the wall time on the build host though - that doesn't include the manual effort of any broken builds. If someone wants to take on this job for ARM and/or for AArch64 when I release it to the wild, they can look at the cross compiler toolchain and set it up - it's easy enough to do (Brent Earl is using it to help with AArch64).

For tagging packages that are known unbuildable, perhaps that'd be better marked out on the SBo web site on a per package basis.
However, like most things - it's easy for me to think up ideas but I'm fully aware of the time and effort involved in both getting up and running, and long term maintenance, and encourage people if they are interested, to perhaps try it in private for a few months and later review whether that's something they would like to commit to; otherwise it'll be disrupt the upstream SBo developers and waste the energy of multiple people and have no long term sustainable result.

Building for AArch64 even natively though (at least on the RockPro64) is worlds apart from 32 bit ARMv7 though in terms of build speed, so should no longer preclude people from building most packages from source using SBo scripts.
I am planning on doing a short video tutorial to build packages from SBo on AArch64 at some point.

ARM is 32bit so the suffix variable should remain unset/null and generally you do not need -fPIC. I only add it when the compiler suggests it (as your build log does).
AArch64 needs the suffix set to '64', and -fPIC is set within the global CFLAGS settings for all build scripts, with the exception of a handful of packages where it's filtered out within the package's SlackBuild.
As far as I'm concerned, the architecture compiler settings stanza within the linuxdoc-tools package is the correct default set for all officially supported architectures (including AArch64). Note that I don't include -fPIC in there because none of the bundled packages require it, and LDT does not inherit any other settings from the Slackware ARM build environment that override it.


I'll update this doc for Slackware AArch64 before it's released, with the architecture stanza as well.

1 members found this post helpful.

I wasn't implying you should have to build everything yourself. I don't think ponce builds everything, he just coordinates the community reported issues.

Stanza, that's the name I couldn't remember. Off topic, but from the linuxdoc-tools package, is s390 still supported and what will the stanza be for risc-v?

That reduces the scope some what ;-)

Mark Post is still on the Slackware team but S390 is not maintained and I suspect never will be. Risc-v would be -O2.

Dare I suggest replacing s390 with risc-v in the template

I have some experience with building all of SBo. For some time I maitained the documentation for slackonly.com and collaborated with the slackonly.com lead. According to the person building the repository, it took about a week to build x86_64 and a week to build x86. Arm would take multitudes longer, even with a beefy arm device, as MoZes has suggested. This doesn't include rebuilds for security updates. repology.org is your friend in this.

On Aaarch64, I have made some experiments a few weeks back. I was interested in building a large chunk of popular software from SlackBuilds.org (SBo), for Aarch64, to provide for the community. I have several arm64 devices, rpi 3 x2, a rpi4, aside from my rock pro 64. I have an additonal 4 x86_64 set of computers I can use to cross compile. A tool calld slackrepo is the best available software for this task. Slackrepo is what was used for Slack Only when it was still updated.

In addition to slackrepo, I like to tie all of my computing power together with distcc. I think the lead of Slack Only built everything on one Intel Skylake machine with 64GB of RAM. This was a few years ago. With several devices connected over the network, the time could be cut down to less than a week on Aarch64. It is still an immense amount of work with the remaining issue of how the resulting work will be distributed in the end. All the documentation I wrote for Slack Only is somewhat finished and can be found here: https://github.com/panosmdma/SlackOnly-Docs (the ftp/http site overlay) and the SlackBuilds can be found here: https://github.com/panosmdma/SlackOnly-SlackBuilds

I may take up this project for Slackware aarch64 in the next few months. We will see. It is A LOT of work and I would likely do most of it myself.

I don't think one person needs to/should have to build everything. The way I understand the Ponce -current update github is its a copy of the 14.2 Slackbuilds and then as users in the community find issues they report them and Ponce will search for a fix or if the user knows of a fix he will accept it from them. So he doesn't have to build all the Slackbuilds himself. I would imagine a workflow for arm and arm64 and risc-v would work the same, fork the Slackbuilds site for each and let people try them and update as necessary. Though I wonder if a complete copy is even necessary for each as many build without changes so it would seem once 15 is released we could just try the 15 builds and only need to update any that need it. I was trying to think of some way I could help out.

It's not that bad once you get moving. Most of what ponce fixes translates to all of Slackware. The build flags can be set quite easily for every package in slackrepo. Globally or on an individual basis.

Once 15.0 is out such a project is far more feasible. Until then it's best to wait. The beginning of a stable release is usually when Slackbuilds.org is most stable and there are less build failures.