> 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-li...@biscuit.org.uk> > > > ha scritto: > > > > > > > > > Da: Stuart Winter <m-li...@biscuit.org.uk> > > > > > Oggetto: Re: [ARMedslack] Slackware ARM > on Small > > > NAS (NS-K330) > > > > > A: "Slackware ARM port" <armedslack@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@lists.armedslack.org > > > > > http://lists.armedslack.org/mailman/listinfo/armedslack > > > > > > > > > > _______________________________________________ > > > > ARMedslack mailing list > > > > ARMedslack@lists.armedslack.org > > > > http://lists.armedslack.org/mailman/listinfo/armedslack > > > > > > > > > > -- > > > Stuart Winter > > > Slackware ARM: www.armedslack.org > > > -----Segue allegato----- > > > > > > _______________________________________________ > > > ARMedslack mailing list > > > ARMedslack@lists.armedslack.org > > > http://lists.armedslack.org/mailman/listinfo/armedslack > > > > > _______________________________________________ > > ARMedslack mailing list > > ARMedslack@lists.armedslack.org > > http://lists.armedslack.org/mailman/listinfo/armedslack > > > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > -----Segue allegato----- > > _______________________________________________ > ARMedslack mailing list > ARMedslack@lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > Regards David _______________________________________________ ARMedslack mailing list ARMedslack@lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack