If I were to recompile & arch-optimize Slackware, where to begin?

So, the thread title pretty much addresses the scenario; now I have 2 questions:

1 - What to re-recompile? EVERY last binary/every drop of code on my system? Or perhaps, everything in /bin /usr/bin /sbin and X and KDE? Or what-all?

2 - Is there an efficient way of going about this? This is going to take forEVER!!

Thanks!

PS - I'm on dialup-- and it's SLOW.

Well, if you have the Slackware install DVD or CDs 3-6, you'll have the source code for all the programs in Slackware. And, what's even cooler, is that every one of them (AFAIK) has a *.SlackBuild. Now that makes it quite easy to compile each one from source. Yeah, it'll take a while tho.

One more thing: Why do you want to do this ?

It won't help as much as you think it will. Try compiling some large programs from source with whatever CFLAGS you think are best. Typically, if it's a game, I've gotten a 1-5 FPS difference. Really, considering the accuracy of the measurements ... this is negligible. Now the theory is, if you recompile everything, the speed gained in each will sum up to render everything much faster ... well it will be faster ... but negligibly so

Is your system that slow that you need to re-compile all of your packages?

If so, why are you using KDE and if your system is that slow then surely re-compiling all the packages will take a very long time.

@ TexmeX - Yup, I do have the DVD, and it DOES have all the source and SlackBuilds to my delight, and that is exactly what I've been doing: adjusting the build scripts and sometimes the makefiles, and compiling it that way.

@ Crooksey - Why? Because I can . And no, my system is quite zippy as a matter of fact, @ 2.4 Ghz running Slackware; I just want to see how much zippier it can be with a fully optimized OS built on it, for it. I like trying to go for the utmost in performance, so running an i386-generic build on a i686 machine is not in line with this goal.
I prefer KDE over the others I have tried. And it runs perfectly fast.. Just not quite fast enough.
Again -- because I can, and I have the time, and I see the opportunity to learn a thing or two.. Also, as my kernel is already (long ago now) tuned to my CPU/Architecture, how better to take advantage of that than to run a matching system around it?

Thanks H_TeXMeX_H <__ Hey did I get that right finally?

To make it faster, maybe you could write some master script for changing the SlackBuild scripts and then building them sequentially, then let it run for a couple days.

@ Crooksey - Why? Because I can

Lol - you go for it girl !! As H_TeXMeX_H says - putting some prior planning to the time management of this should pay dividends. I've just been compiling parts of KDE in one terminal and watching "top" in another to see how processes and memory are used by the make process/compilation. Interesting stuff. The compiler appears to spawn more than one process as it goes. Maybe I should get out more !! Good luck with your project.

@ bgeddy - me too, maybe I should get out more too!
Thank you for the encouragement, and to you both for the 'master-script' idea. That is a good one indeed, and I bet it's pretty simple; when I get so that I need a break from this I may just start that.
I'll admit, parsing, editing and re-saving files is not within my abilities yet, but I know enough pieces of the process to probably put that together. Thing is, some packages require more than edits of the build script, ie: I need to edit (multiple sometimes) Makefiles on occasion.

One thing I have been avoiding as yet, is dealing with glib/glibc/glib2 and GCC itself-- I understand that BIG problems can arise if/when trying to upgrade or re-install these things, and I'm not sure yet how to go about that.

For now, on with the show
Thanks fellas!

glibc is about the only package where it can be semi-hazardous to upgrade on a running system. But, then again, Pat makes his glibc package, via doinst.sh, able to upgrade on a running system by way of deftly staging/moving stuff around during the install. Anything else isn't a problem to upgrade.

The master script idea is a good one. I'd do a find for loop or something similar to execute each script. Defining your CFLAGS in a ~/.bashrc file takes care of 99% of all packages being optimized. Alltho, you'd probably wan't to do a find/sed command to change the arch in all SlackBuilds since that's where they are supposed to be defined.

It'll take awhile either way, I'm sure.

I recently rebuilt a basic system on top of a running system. Basically you need to create a statically-compiled toolchain and begin by compiling or configuring the kernel sources for the version you want to base on.
Then you compile glibc with the same toolchain.
Then compile binutils linking against the new libs.
Then compile the new compiler linking against the new libs and using the new binutils.
Then compile new libtermcap, bash, zlib, popt, gzip, gettext, sed, util-linux, make, awk, ncurses, readline, e2fs, bin, util-linux and so on. The order can be a little different but is extremely important. Once you get the above list working and system booting with those bins and libs, you can insure even better binary compatibility by recompiling it all under itself before proceeding with the rest of the packages.
Of course programs which depend on certain libraries should be compiled with the newly-compiled libraries installed first. A good way to find out the dependencies for every program and library on your system is to use slackdeptrack. The ouput should help you get things in the right order.
The approach outlined is pretty simplistic and won't work for creating a cross-compiled system where there is no binary compatibility between the running system and the new progs and libs. Most new Slackware versions are created with a similar approach -even simpler since they don't use a static toolchain.
Hopefully, this should give you an idea of the general strategy of creating a system from scratch, without going over the top of your head or mine either. A true cross-compiled system is considerably more complex and some programs must be recompiled several(3-5) times.

why not do the obvious?

read http://www.linuxfromscratch.org/

Originally Posted by GrapefruiTgirl I just want to see how much zippier it can be with a fully optimized OS built on it, for it.

Probably nowhere near what you expect.

That said, Slackware makes a good choice for an experiment like this, since it comes with all the source code and build scripts.

Originally Posted by GrapefruiTgirl I like trying to go for the utmost in performance

Are you sure you're not a Gentoo user...?

gnashley - your contribution(s) are always most helpful, and once again, you've hit the nail right on the head.
As is often the case, I dove in head first despite being unsure about a few things, and even though all is going well, I might have to take a step backwards: I should have started with a fresh statically compiled toolchain I guess! And I would like to 'upgrade' my running system rather than actually 'create a new OS aside from it'.
I'll have to look into the details of making a new toolchain first (after finding out exactly what a toolchain is comprised of) and go from there.
A few points:
1 - I'll go with the 2.6.20 kernel I am running now; I like it. Just need to get the headers.
2 - I'd like to use the latest stable glibc and GCC.
3 - I'm not cross-compiling.

I downloaded the text version of the first LFS stable book, and will likely find loads of good stuff in there, hopefully a concise list and order-of-construction of the things you mention above: the toolchain, the kernel, glibc, binutils, and the rest of the gadgets...

I also downloaded 'slackdeptrack' and it's pretty outdated and unmaintained, but maybe it will give me some useful basic info about the dependencies, indicating where the 'top' is and what trickles down from there.

@ erlaerbaer - thank you for pointing me towards LFS maybe when I'm done, I'll call it "Scratchware", it seems LFS is right up my alley, but I am now IMO a dedicated Slacker, so I hope I can adapt the principles of LFS to re-making my own Slack system.

@ rkelsen - perhaps 'not what I might expect' but then, I don't know what to expect really, except to have learned from my experience, and be happy in knowing 'I did it' -- It's something of the "I think, therefore I am.." argument; my system isn't slow, but I'll be happy to know I have built it from the ground up and that it is working as best as I can make it. Hard to believe a person like me (and surely MANY others) have remained complacent for so long by running that 'other' OS -- this is just so much cooler!
Finally, I 'did' try Gentoo a few times, though hardly gave it the 'full college try'. I have a Gentoo here on CD, and may try it out again and again, but so far, I'm just not attracted to it (the crowd chanting 'Slack--er!!...Slack--er!!....Slack--er!!')

Thanks everyone -- I'll be in touch!

Originally Posted by GrapefruiTgirl maybe when I'm done, I'll call it "Scratchware", it seems LFS is right up my alley, but I am now IMO a dedicated Slacker, so I hope I can adapt the principles of LFS to re-making my own Slack system.

I've been doing the same thing for quite a few years now, if you'll notice my sig... http://www.jaguarlinux.com/

It is much more rewarding than running a pre-compiled distro, tho I still dual boot with Slackware... I happen to prefer DIY linux over LFS tho... It ussually always results in a better system, plus it's package manager friendly whereas the LFS devs are insanely opposed to a package manager and scripting in general (following the discussion of modular X was quite entertaining to say the least). Even so much as mention the words package manager, script or even CFLAGS on the mailing lists and you'll see some very anti-social behavior. That same ridgid thinking can still be seen in the LFS book today... No thanks... But, it is a good starting point for people just getting into it...

Have fun with it and change some stuff around, otherwise your just running an i686 slackware...

I highly recommend jong357's system for the most thorough rebuild. My notes are meant to give the broad overview which is usally lacking in discussions about re-compiling.
This method can work if you have enough statically-compiled tools to keep running as you install over existing files or bootstarp from an otherwise empty partition.
A toolcahin consists of of a compiler and binutils which are linked to the target glibc version. But you also need bash, sed, awk, make, tar, gzip and many of the util-linux tools. Most of these can be covered by using a statically-compiled busybox (except make).
You say you are not cross-compiling, but if you are upgrading to a major version of glibc you may encounter the some of the same problems. If your shell and other existing dynamically-linked tools will not run under the new libs then you have to do a lot of special linking using LD_LIBRARY_PATH and changing which binaries are being used by adjusting the PATH several times and/or using chroot.

jong357's documentation probably will give you a clearer idea of the concepts than the LinuxFromScratch docs.
BTW jong357, my recent releases of the src2pkg package-building software include easy compytibility with jaguarlinux desc files and can be used to bootstrap your system from sources and scripts on the network.