[armedslack] Armedslack Current

Stuart Winter m-lists at biscuit.org.uk
Sat Mar 31 20:50:56 UTC 2007


> I am not really fond of huge build scripts. Not because they're not nice or
> useful.
> But when (not if but when) they produce errors, you have to fix them and
> restart
> the entire build script

Yeah I know but I do prefer large scripts - I get a sense of
accomplishment, scrolling down a few hundred lines of code :-)

With the X11.SlackBuild in -current, you can specify individual
components to rebuild so it's not so bad.

I also have 5 machines here doing distcc cross compilation from the
qemu ARM machine.  It's pretty cool, although I still would
prefer to be running on my real ARM box - the Iyonix.; but Castle
don't seem to be interested in making a 2.6port :(

> There is nothing wrong with that but what I meant to do was rebuild for a
> processor
> model on the same architecture so building and optimising for a certain
> processor
> (on possibly another architecture) would be easier the next time.

Oh OK - I have had a look.  How would you differentiate package
names from the resulting build?
Originally I used 'foo-1.0-armv3-1.tgz' because I thought I would make
an xscale specific set of packages, but somebody told me that even
Debian don't do that, so I probably wouldn't have time.  They turned out
to be right.
Although with little ARM gadgets, you'd probably just produce a specific
set aimed solely at that individual gadget?

> That of course depends on Patrick's approval. But I already have made my first
> real
> contribution to Slackware through the gcc build script that he has integrated
> almost
> unmodified into slackware-current

Ohj so it was *you* who missed a \ off the end of one of the cp's for
some docs ;-)
I have talked to Pat ages ago about making the scripts more portable, and
he's talked recently about using shell macros (like armedslack's scripts)
in his own build scripts.  I think I'll just keep with how I do things
though.

> The other one was my advice to him to rebuild oprofile with gcc 3.4.6 for
> system
> consistency, something you didn't/don't seem very happy about :-)

Did I even build it at all? :-)  I think I had to build that on the
RiscPC originally because it required Linux 2.6 and that was the only
machine I had 2.6 running on.

Well if you have any input, feel free to suggest it.  I can add in
your other architectures into my build scripts if it helps - although you
say you use your own.

> See the attached fuse build scripts for an example. Adding another processor
> model just adds another patch to the build directory. I have also added a
> (very
> long !) list of ARM targets that packages could be made for. I have a few
> more,
> but they're for x86, ppc, sparc and mips.

Hm.  I try to keep clear of patching the source because it means much
more of a time consuming job for me - usually I just overload CFLAGS or
use sed to update a Makefile.  This full time job and life thing makes
me optimise one of my hobbies as much as possible :)

> I have consulted Wikipedia for this but since you're much more knowledgable
> about ARM architecture than me you could probably point out some errors.

Heh. Actually I used to get really confused about the ARM target names
when I first started, and to be honest I'm still not sure of all of them -
there are so many.  I remember when I was first deciding which -march
value to use, and was browsing usenet and checking what the NetBSD folks
had been talking about.  And then I made a bunch of packages with
some suggestions which turned out to *sort of* work on the RiscPC, but
the binaries produced really weird results.  Eventually after discussions
with a fee people, settled on the ones I use now.

I have never done any tests to see how much difference compiling
for xscale rather than armv3 makes. ARM Linux is just slow anyway - I
doubt you'd really notice ;-)

> That would be nice, especially if you already have some X11 fixes :-).
> I'm running Windowmaker in Armedslack 11.0 with xorg.conf-fbdev BTW
> and it's pretty responsive.

Yeah I used WindowMaker on my 257MHz RiscPC and it worked.  I also
loaded up firefox and was surprised that it was actually usable!
(Well, mostly).

I do not have any X11 fixes aside from what I took out of Debian's
most recent xorg 7.2 patch set.  Since Debian have now discarded RiscPC
support, I'm a bit concerned that there will be no new patches.
However, I did check through their old patches and found that all but 1 or
two have made it upstream.

The real armedslack master tree is here:
 rsync -P bourbon.biscuit.org.uk::armedslack

That'll be a lot faster than ftp.armedslack.org ever was.

> Firefox and KDE are too heavy but this would also be the case on a Pentium,
> so the emulation is pretty accurate in comparison to real hardware.
>
> I'll just try to install my local version of Armedslack Current in a QEMU VM
> and
> see how far I can get. Using QEMU sure beats buying an ARM Versatile board
> for $5000,--, it's just as fast and immensely cheaper.

Yeah - and just buy a faster PC and it'll be actually faster than a real
Versatile board anyway! :-)

The only thing I have found is that building Perl inside QEMU fails, where
as it works on my real ARM box.  I don't know why that is, but it's
no big deal.  I cheated and built the perl in armedslack-current
on my 11.0 machine ;-P  I'll rebuild it later on -current on the
RiscPC.

s.




More information about the ARMedslack mailing list