[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