[ARMedslack] Slackware ARM on Small NAS (NS-K330)

[Davide]

> ftp://ftp.armedslack.org/armedslack/armedslack-current/source/README_SOURCE.txt
> Read that and download the slackware64-current tree
> (including sources)

What's the difference between 
ftp://ftp.slackware.com/pub/slackware/slackware64-current/source
and
ftp://ftp.slackware.org.uk/armedslack/armedslack-current/source/ 

Is it "Slackware ARM only includes the sources in situations when .... " ?

At the time I worked on something I liked to call slackurus I had a different approach: I used to fix the slackbuild scripts so that I could use them for building binaries for zaurus by cross compilation and I had my own overlall build script that looked for packages to build and built them.
But at that time either armedslack was not around or I did not know about it ... way back in 2004 ... well also many other things might have changed ;-)

> cd armedslack-current/source/l/glibc
> sed -i 's?armv4t?armv5te?g' glibc.SlackBuild

Ok that will change just one thing in that buildscript:
-march=armv4t to -march=armv5te

> Change the BUILD number in the arm/build script to whatever
> - increase it
> or make it your own stamp - eg 4_davide
> 
> Start the build (under screen would be better incase your
> host machine
> dies!)
> 
> On a sheevaplug the build takes about a day to build
> natively:
> 
> ./arm/build
> 
> Then your packages will appear in the
> armedslack-current/slackware/{a,l}
> directories.

Will this build everiting ?
Can I just rebuild glibc or is it necessary to rebuild every binary that links the new glibc ?
I was hoping that since version will not be changing maybe I could do with just slipping in the new armv5 tuned glibc: am I wrong in hoping this ?

> > I wanted to get all I can out of my dockstar if it
> works well I might even do that on my zauruses (C
> 760/860/1000).
> > The zauri should all be ARMv5 as husky boxer are
> PXA255 and Akita is PXA270.
> > While the dockstar I'm not sure but I think it's ARMv5
> too.
> >
> > It would be the first time I look into rebuilding
> glibc in order to get better performance and actually I
> don't recall ever doing it at all so if I did I just
> followed the build scripts to build it. Any help is
> appreciated for this task.
> >
> > Regards
> > David
> >
> > > I think it has but I don't recall anybody having
> done it.
> > >
> > > What hardware?
> > >
> > > I'm quite interested in it because I'm still
> thinking about
> > > building
> > > armedslack for armv5te (it's armv4 at the
> moment).
> > > We need some valid test cases.
> > >
> > > On Sat, 30 Apr 2011, Davide wrote:
> > >
> > > > I'm interested in the recompiling glibc
> thing to
> > > regain speed on specific hardware: has this been
> discussed
> > > in the ML previously ?
> > > >
> > > > --- Gio 21/4/11, Stuart Winter <m-lists at biscuit.org.uk>
> > > ha scritto:
> > > >
> > > > > Da: Stuart Winter <m-lists at biscuit.org.uk>
> > > > > Oggetto: Re: [ARMedslack] Slackware ARM
> on Small
> > > NAS (NS-K330)
> > > > > A: "Slackware ARM port" <armedslack at lists.armedslack.org>
> > > > > Data: Giovedì 21 Aprile 2011, 17:49
> > > > >
> > > > > > I don't know, but I don't think
> you'll be
> > > happy with
> > > > > it regardless.
> > > > > > The transfer speeds are going to
> be terribly
> > > slow -
> > > > > bottlenecking
> > > > > > due to the usb2 speeds *and* the
> general
> > > wimpiness of
> > > > > the hardware.
> > > > >
> > > > > Yeah having built the distribution on
> 287MHZ
> > > RiscPCs for a
> > > > > couple of years
> > > > > with 256MB RAM... I don't know how I
> kept
> > > going.  I
> > > > > guess because there
> > > > > wasn't any better or faster supported
> arm
> > > hardware at the
> > > > > time, so I
> > > > > didn't have anything to wish I could
> have ;-)
> > > > >
> > > > > I wouldn't bother with it. Some devices
> use lower
> > > speed ARM
> > > > > CPUs but their
> > > > > usage (and software) is tuned to the
> device to
> > > match the
> > > > > usage with the
> > > > > device's specs.  Slackware ARM is a
> generic
> > > > > distribution built to run
> > > > > on the widest range of products
> possible, at the
> > > expense of
> > > > > speed in some
> > > > > areas (which IMO can easily be
> re-gained by
> > > recompiling
> > > > > glibc and some
> > > > > other critical libraries; but that's
> another
> > > topic :) ).
> > > > >
> > > > >
> > > > >
> _______________________________________________
> > > > > ARMedslack mailing list
> > > > > ARMedslack at lists.armedslack.org
> > > > > http://lists.armedslack.org/mailman/listinfo/armedslack
> > > > >
> > > >
> _______________________________________________
> > > > ARMedslack mailing list
> > > > ARMedslack at lists.armedslack.org
> > > > http://lists.armedslack.org/mailman/listinfo/armedslack
> > > >
> > >
> > > --
> > > Stuart Winter
> > > Slackware ARM: www.armedslack.org
> > > -----Segue allegato-----
> > >
> > > _______________________________________________
> > > ARMedslack mailing list
> > > ARMedslack at lists.armedslack.org
> > > http://lists.armedslack.org/mailman/listinfo/armedslack
> > >
> > _______________________________________________
> > ARMedslack mailing list
> > ARMedslack at lists.armedslack.org
> > http://lists.armedslack.org/mailman/listinfo/armedslack
> >
> 
> -- 
> Stuart Winter
> Slackware ARM: www.armedslack.org
> -----Segue allegato-----
> 
> _______________________________________________
> ARMedslack mailing list
> ARMedslack at lists.armedslack.org
> http://lists.armedslack.org/mailman/listinfo/armedslack
> 
Regards
David