I was wondering how you guys created Slackware64, either from scratch or an import, but because a lot of the packages seemed on par or minor updates to Slamd64, it might have been unnoticed what was done.

The thing is Ottavio, is existing SlackBuilds can be rewritten to use the same source, yet also use different patches, build flags, optimizations, etc. specifically for ARM. This way, the source can be self-contained across all platforms with only needing one script for one source, yet patches and architecture specifics kept reserved as needed.

That already exists in slackwarearm aka ARMedslack. I would prefer Alien Bob's integrated solution -- while I realize ARM is a different beast (and though I am very far from an expert in the matter I have used embedded Linux on ARM devices), slackwarearm really is a different project. You cannot apply your knowledge of Slackware to slackwarearm and work as usual -- (re)building official packages demands that you learn a whole other process, which although efficient to maintain from Stuart Winter's point of view (and possibly the only way to maintain such a project as a single person), becomes a frustration from not being able to use Slackware in the same way just because of an architecture difference. Obviously ARM's kernel requirements make a catch-all distribution impossible but a unified Slackware ARM port would be highly desirable, at least to me. Note that I do not intend to diminish the ARMedslack project, which is and has been fantastic.

I don't understand a word of what you are saying here.

Eric

I need an arm cross compilation environment to do some work on an embedded device. Previously I'd use code-sourcery's lite g++ toolchain, or build one using Open Embedded.

If I understand correctly these scripts would build a Slackware package containing an arm cross-compilation toolchain I could use on an arm9 embedded device? If so that would be awesome!

The script first creates a subdirectory structure with a suite of cross-compilers (i.e. compilers running on the x86_64 host but capable of creating arm binaries) and the second stage is to use those cross-compilers to compile a mini root filesystem which can be installed on the ARM machine. This rootfs contains a U-Boot kernel, so it could even be used to boot the ARM computer if you know how to configure U-Boot. The rootfs contains the necessary tools you need to build all the rest of Slackware from scratch on ARM.

I'll have to consider creating a github repository for this. The scripts are not secret, it's just that my port is incomplete and I wanted to wait. It is pretty rough at the edges still.

Eric

Should I upload a ZIP with the crosscompilers so that you can test? I have one for Slackware64-13.37 - since that is the version I run on my development box. I can rebuild one for Slackware-current but that may take a little while to check the newer package versions.

Eric

If you've got time I'd be pretty interesting in playing around with it. Current would be ideal but I've got a SW64-13.37 laptop which I could use. I pretty much just need a arm-gcc toolchain so I can compile some homegrown programs and run them on a little ACME board running emdebian.

Slackware ARM/ARMedslack started as an unofficial port, so I had to out of necessity have a separate tree, that was easy to maintain (which is still is, at least in terms of keeping up with x86 development). There's now over ten years of development history there which even now is still quite useful for me when developing.

For those who are saying how it'd be easier for *them* - I'm the only one who develops Slackware ARM, so it has to be the easiest for me to maintain. Since Slackware is not a 'from source' distribution such as is Gentoo, there's no need for everyone to understand how to use my build system up front. However, I have made ample effort to document it - and the Slackware ARM source tree and build scripts are sometimes more verbosely documented than x86 (mostly for my own benefit in the first instance, but for those of you want to read and learn, it's there in the open). On the other hand, did anybody really try using the x86 scripts? From some of the posts it doesn't sound like it. If you did, you might find that many of them are perfectly fine on Slackware ARM as is, with no modification -- since a while ago, Pat took the auto arch detection & CFLAG settings from my scripts and added them into the x86 tree. The CFLAGS are for armv4t in there at the moment, but it's no big deal to change it if you so wished.

None of us apart from Pat are able to make changes to the source tree, so it's *far* easier and less time consuming to have a separate tree in order to fix bugs and apply patches quickly. Obviously if I fix something for ARM that applies also to x86 then I give Pat a heads up.

As anybody who's programmed or scripted -- you develop your own style. As some of you who've perused Slackware ARM's source tree will see, the build scripts are somewhat different (although the main sections are the same). Part of my enjoyment (albeit only a small bit) is coming up against something in the x86 scripts that I'll optimise or just re-style to my own taste, but still achieve the same resulting package.

Finally, the current SlackBuild scripts need further work more than just setting some CFLAGS. There are some obvious ones that spring to mind such as using gzip to compress packages rather than LZMA; since many ARM devices don't have much RAM so I foresee trouble with LZMA on ARM. There are a few other points to consider (which I've discussed briefly with Eric & Pat but don't recall them off the top of my head), but until such a time that my interest wavers in maintaining my own scripts or we're able to make changes to the source tree, and figure something else out with regard to how packages are built, then it's definitely best to keep the projects separate. If I found it too tiresome having a unified tree (as at present it'd essentially be a case of bugging Pat to replace or apply a patch to an existing script), I'd just stop working on it and do something else.
At the moment since I've been building the ARM port for a long time, I know when to batch up my updates as I have developed a sort if inner compass for knowing when an x86 batch will be 'buggy' -- so I tend to just leave the ARM packages for a few days and this way it saves me having to rebuild them 2 or 3 times before I upload them and they're listed in the changelog. For large packages such as QT this is essential since that one takes about 1.5 days to compile. However, this approach means that if we *did* have a unified tree, then the build numbers would be out of sync. I like having sequential build numbers which you can track in the changelog, rather than say jumping from 1 to 4. Given that the build/queuing system is manual (unlike Fedora, Debian etc) and is done in spare time, what I am saying in a nut shell is that the system has to benefit the person who uses it, not the other way around :-)

Phew. Anyway, I don't think I could ever lose my library function names. Who wants to reduce a changelog with some heading and tailing when you can call "slackliposuction". I just imagine a big machine sucking all the text out of a file ;-)

Stuart,

I have been using your arm port for a couple years now on some of the plug computers. You have done a fantastic job with it and produced an excellent distribution. I am really just posting to say thank you so much for all your hard work on the project.

I would like to associate myself to this comment of gratitude for Stuart's port, although I haven't tested it that much and only on Qemu, but I am planning to buy the latest Genesi iMX.6 device whenever it comes out.

I have to say I'm interested in something similar.
The closest I have found is either openembedded:
http://layers.openembedded.org/layer...master/layers/
Or the Yocto Project:
https://www.yoctoproject.org/

With a bit of work these will build from ground up functional systems using bitbake(.bb) "recipes", for a variety of targets, (quite a bit like slackbuilds or Linux From Scratch).

I have tested in that I successfully built and tested the intel mobile access point:
https://metaeca.wordpress.com/
but quite a few other package layers are available...
or someone could write their own layer...