Sorry for not responding before I had no idea I'd get this many responses!

Typically you'd set your CFLAGS CXXFLAGS and have them exported according to your cpu specs in your etc/profile. Then you can just start compiling and install your own packages from a standard install. But I wanted to do everything down to the bone. Yeah the reason for recompiling is to get any speed boost I can and especially to learn how to do so on my own, and maybe edit a few packages here and there. Preferably the entire system. Why not? It's basically sitting there telling me it's ok to do so. It doesn't mind! I use a prescott Celeron D 330j (soon to be e5300 hopefully!). Yeah takes quite some time.

Yeah you can use Gentoo which is total bliss with dependency tracking and having everything automated which is great, but sometimes you wanna be on your own without any distro's automated process getting in the way, and especially to learn. You can't learn anything if you got something else doing it for you. I don't get why people make a big deal about Gentoo being so technical. It is technical compared to something like Ubuntu but it's still doing most of the work for you (emerge), it's also great for that reason (if that's what you want it's alot easier).

This is what's so great about Slackware I.M.O. cause you learn so much as far as linux goes and just *nix alone. It's pretty much a pure *NIX environment! It's good to have this available since every other distro has their own automated process to avoid being completely on your own (Ubuntu is great for those people). This is also the reason why I said you're completely on your own since there is pretty much nothing tracking dependencies for you. Hell it even comes pre-installed with several Window manager's! Slackware doesn't care what you do with it! Any program you want to install has to be compiled from source first and then installed. Preferably made into a suitable package and then installed via installpkg (checkinstall I recommend but you have to download it). Yeah sure there are places you can download pre-made packages for installing into your slackware which is great, but you gotta find them, and/or use someone else's program for finding them (slapt-get is a great one). Also you have to be running a stock Slackware to use them otherwise there might be some quirks. Or even worse you have to update your system according to the way that person has their packages setup! Using absolute linux packages (pcmanfm) on a standard Slackware install is an example of that. Once you update GCC, Glib2 and the like you're not running a stock Slackware install anymore. I.M.O. Slackware is made for the user to mess around with and do what he/she pleases in order to have their computer as they like it. You can't do that by using other people's packages. If you wanna be totally independent. Slackware I.M.O. is the ultimate linux O.S. in that regard. You can do anything with it without a set standard getting in your way. You'll be able to do a LFS just by learning around Slackware.

I use Gentoo but if I wan't something that works with no fuss or dinking around Slackware just get's you there. You can decide to leave it alone and use it the way it is, or you can then dink around and recompile everything if you want inside an already running window manager and have all the tools already available! I guess Sabayon is like that too though but then again not really... Lol.

Yeah I use Gentoo but Slackware I.M.O. is the ultimate leethaxorZCFLAGZOMG-sCriPTzPWNED O.S., yet at the same time it can be left alone and be completely stable! You can do one or the other it won't stop you at all! You can make it impossible for people to know what to do or what's going on. It's the best! haha.

2 members found this post helpful.

About couple of years ago (Slackware 11?), GrapefruiTgirl tried to recompile/customise Slack to suit her hardware. Her motherboard blew up ( or something) half way through, so I'm not sure whether she completed it. There was a long, interesting thread about it.

Thanks for the feedback! As the old saying goes;

"If you get Red Hat, you'll learn Red Hat. Get Debian and you'll learn Debian. But get Slackware...then you'll learn Linux."

Keep us posted! I'm interested in how your cross-compiling efforts turn out!

Holering,

Good work!

I've basically run nothing but Slackware from 2003 until last year. Then I started running Gentoo on the same hardware and found that compiling with proper flags for my Athlon 64 X2 5000+ desktop, and my Lenovo T61 Core2Duo T8300 laptop (rather than for the lowest common denominator as Slackware does), made a huge, noticable difference. It ran like a newer, much stronger comp -- it was simply amazing.

This got me started thinking about rebuilding the entire Slackware system, but so far all I did was make custom SlackBuild scripts for things such as Mutt, that I always have to rebuild anyway; and other software such as dcfldd, rxvt-unicode, and aria2 -- which aren't included in Slackware. Also writing new SlackBuilds for some other apps and saving them for later.

I'd also put off rebuilding entire Slackware because we're starting a computer consulting business here, and once it's open we have some operating capital to use. When that happens I'll be building a new desktop with at least a 4-core CPU, and building or buying a new server. So I was thinking to just wait, since the CFLAGS will be so much different for them. And in the meantime, saving all my new SlackBuild scripts with custom CFLAGS, ect.

Also just this month I stopped using Slackware64 because of (a) problems with 13.1 and -current that aren't in the 32-bit version, (b) software that is only 32-bit such as Skype and QQ; (c) I don't have any individual applications which need more than 4GB of RAM, (d) I don't use any applications in Slackware which benefit from native 64-bit computation.

However, after reading your thread, I'm going to go ahead and start building this custom Slackware on my T61. It's not going to change, anyway. Just never thought of trying to compile it all at once the way you've done.

Thanks for your post!

2 members found this post helpful.

Yeah I've been running into this problem. For every problematic package I just used the developers latest version of that package and got rid of any patches in the slackbuild (or anything else it took to get it to work!). It was sort of pain but eventually I got it.

I had a major problem with shadow! Omg! I couldn't log back into my system not even as root! So I went back to the standard i486 binary of shadow and that solved my problems. I did that by running another linux distro and manually extracting the i486 bin of shadow into my slackware install. Until I figure out the problem with shadow I'm just gonna use the i486 binary. I don't think shadow would benefit from recompilation anyway (i'm almost positive of that) but it still bugs me lol. I hope this serves as a warning to others recompiling and doing a simple upgradepkg *.*z inside the a folder!

It's alot of work recompiling slackware, but I think the example's I've given previously are a good headstart for anyone looking to do such a thing. If your going to do a minimal install (or somewhat minimal) I would recommend upgrading to latest GTK+2.X, glibc, glib2, xorg, and any other major dependencies that the rest of your system will build from. I'd say upgrade GCC as well but there may be some slight issues that are not worth the upgrade and time. They could simply change something that could mess up the rest of your slackbuilds-packages. Definately make sure the kernel headers are the ones you want as that's the first thing you build from (glibc depends on your headers!)

3 members found this post helpful.

Did you keep notes on which packages you needed to give a version bump?

That's good to know! I wonder why there's such a difference.

Are you seeing a real performance increase?

Regards,

No I didn't. I didn't need to give a version bump to any package. I only did it because I wanted my system up to date and bleeding edge even though in some cases it made things easier, but then again sometimes not. I want to keep the most important packages up to date especially against stable kernel headers (kernel 2.6.35.4 stable as of this post). In my case I just copied the source folder from the slackware dvd (13.1). I replaced all the old packages with new ones from the developers website. Especially the kernel headers, glibc, binutils, gcc. I changed my mind about keeping the older gcc and just used the latest along with automake, autoconf and all other development tools. Sometimes you run into something that upsets your but then you just figure it out and it's done! I also like compiling right before I go to bed or go do something. I'll still compile even when I'm using my comp to archive music, while I'm browsing the web or playing games. It's amazing how much you can do with 1gb of ram and a 3.33ghz prescott cpu!



Yeah it was scary! I couldn't log into my system at all! I don't think it's a big deal to just use the stock i486 binary instead of rebuilding it for my system. I'll probly try again later with the developers latest build of shadow and hopefully it won't be such a big deal...



Well it feels like it but then again I'd rather measure performance through benchmark programs (phoronix test suite perhaps?) so I can prove it. Especially against gentoo. I just wonder if/how gentoo is building the base headers, binutils, glibc and gcc optimally. It's also nice knowing how your software is running solely for your architecture. It reminds me of video games how their built from the ground up for a specific game console. Most software is built for x86 cpu's which is what almost everybody has. You just gotta take advantage of your particular x86 architecture which is what makes all the difference really.

I think the biggest difference i've noticed with iX86 vs custom cflags (at least on my system) is with smaller programs and window managers, and probly even games. KDE4 was noticeably faster in gentoo vs the one in my old standard slackware install and that is a bigger window manager (biggest perhaps?). I don't know how it'd be now since I don't use kde4 in my current slackware and now that it's optimized.

When I used to watch youtube 480p flash videos in google chrome full screen, the buttons wouldn't respond right away and the video became noticeably choppy. Now it doesn't do that! Everything is instantaneous when I click pause or skip the video. I can scroll up and down Web pages with lots of images and flash ads with no lag and it's fast! It wasn't like that before. This was when I used window maker in my standard slackware. It's the same thing now except it's all optimized for my system! I think it could be related to the sse instructions vs standard i486 but I don't know for sure.

I have a celeron D 330j @ 3.33ghz(socket 775 soon to be e5300 hopefully!). It's basically a prescott pentium 4 with less cache so it's one of the better celerons and it's not 64 bit. It's comparable to something like an athlon xp 3200, pentium 4 3.0ghz or so (when overclocked of course). My flags right now are -march=prescott -mtune=prescott -O2 -msse -msse2 -msse3 -mfpmath=sse -msseregparm -fomit-frame-pointer. I could probly use some crazy flags here and there but I'll do that only with emulators and games. I don't think it's worth using questionable flags for your actual operating system! It's supposed to be stable right?

@Holering
Thanks for the update!
Out of curiosity, did you change any of the static/dynamic compile options to save space?
I know back in the day you could compile the "Stage 1" installer (basically, compile a compiler, and everything you just mentioned). However, now days I'm pretty sure you can grab a architecture-specific "Stage 1" tarball that's tweaked appropriately. (After all, no matter what options you use, the bin-utils are only going to get oh-so-fast.)

Ok my mind got a little sticky about whether I should start a new thread or not but here goes... Oh and I also wanna give my thanks for slackware. This is the first linux distro that I tried when I first tried linux. I just can't believe how coincidental it is that it also became my favorite and it's also considered the most pure *nix system. Sweet!

Not really. I remember seeing glibc (or maybe gcc. I forgot now...) having -O 3 and I changed it to O2. From the benchmarks I've seen it seems O 2 is just all around better and faster. O1 seems faster with mp3 encoding. I'm interested in using O s and maybe O1 for some applications like audacious.

Ok so I'm running every slackbuild using the previous script-example shown in this thread, and I'm running it inside each source directory. So lets say I run the script inside the source/a/ directory then I get all the packages shown up in the /tmp directory as *.txz. All the packages in /tmp/*.txz would be the ones built from the source/a/ of course. What should I use to make a directory somwhere like /home/user/slackware-prescott/a/ and then put all the /tmp/*.txz packages that were built from the source/a/ directory to put them in there, and then mv all the /source/a/* directories that were successfully built into /home/user/already-built-sources/a/*.

My minds a little numb right now but I'd like to make this process as automatic as possible so I can set it and, forget it. I'd Use the previous examples to replace c and cxx flags, run every slackbuild script, run a script that renames all the packages in /tmp/ from *i486*.txz to (whatever your architecture is) *prescott*.txz (here's what I use but beware it can be dangerous if running it as root! You don't wanna rename the wrong files ya know! | for old in *i486*.txz; do new=`echo $old | sed 's/i486/prescott/g'`; mv $old $new; done | ) , then finally have every built package moved to their proper corresponding directory /home/user/slackware-prescott/a ../ap ../e ../d ../etc..., and then have every successfully built source directory moved to /home/user/already-built-sources/a/* . If any packages failed to build for whatever reason their source directories will still remain in their source/*/* folder and not moved of course.

So yeah this is a bit stretchy (crazy?) but this could be a nice script that you can just run, set it, and forget it; for whoever would like their slackware installation arch optimized according to their hardware. Being able to run a script like this is nice compared to other distro's where you rely on their entire package management and their stability (gentoo's emerge). Plus you could use it for future version's of slackware. Of course you'd wanna make sure your installed headers are the latest stable ones (you can extract the stock headers and then replace the files with yours and then makepkg into a new up to date header package! Don't forget to inspect the install script and edit accordingly...), compile glibc (i'm using the latest one. Even slackware current doesn't have it), but don't install the glibc-solibs package quite yet just the others first! Then compile gcc with your newly installed glibc (the slackbuild runs tests to make sure it's ok), then binutils, etc. Ok now your gonna have to rebuild binutils, then gcc again and so forth (I'd first rebuild glibc just to make sure haha). Yeah you gotta go through 2 or maybe three passes on those packages glibc, binutils, gcc to get every ounce of juice out of em.

I can't say for sure how many passes I did on em (I think it was 3 instead of 2) but I didn't even need my backup slackware install which I made just in case. Basically I kinda followed linux from scratch chapter 6 book (stable) and went from there. I can't remember when I installed glibc-solibs glibc-zoneinfo packages but I'm sure it was after the first pass... I did all this while being inside a window manager browsing the web and I didn't have any issues! Just had to make sure I used upgradepkg to install everything (especially glibc-solibs!!). Didn't get any missing icons, fonts or anything some people report (even I suffered this in the past when I was less experienced) when upgrading glibc packages and I hadn't even started building X dependencies or gtk stuff yet!

I'm sure it'd be way faster on other people's machines compared to my lowly celeron D prescott @ 3.33ghz. I envy those who even have an athlon II x2. Just be careful with glibc-solibs and shadow! Eventually I wanna put it all together into a script that will build-install headers,glibc,gcc etc in the proper order and passes and then finally building the rest of the packages. I use linux from scratch book to know what patches are needed and what not. But I wen't back to gcc 4.4.4 since I didn't wanna mess around too much plus it's very mature and stable (gcc 4.5 is only 4.5.1).

I don't even think many gentoo users now are aware that installing from a stage 3 install you still gotta bootstrap-recomple the stage 3 packages multiple times before you proceed with anything else. The gentoo handbook doesn't even mention this and they don't support stage 1 installs! Users who aren't aware are still getting speed boosts I'm sure but not all they can get (which is probly not noticeable anyway). It's very sketchy when you do an emerge -e world twice. lol

The next thing to do is figure out which packages depend on what and build in the proper order. That would avoid the user having to do a second pass just to make sure everything's built against the optimized libraries. But yeah that's just silly and it's way easier just to do two passes on everything. I'd never wanna do that but who knows I might study 1 package a day and then in a year have the right kinda build chain. That's just crazy though...

Hello Holering,

a very interesting thread.

Gentoo provides the Useflag "bootstrap" for packages like gcc, so one won't have to rebuild the whole world.

Since you complain to have such a slow machine, did you think about using ccache and distcc? both packages are part of Slackware.
ccache provides a cache for the compiled binaries. distcc allows you to distribute the gcc-jobs to other Machines in your network. If you're crosscompiling, you'll have to build a toolchain in order to create the proper binaries with distcc, http://www.gentoo.org/doc/en/distcc.xml

Markus

Holering, I hate to burst your bubble, but simply 're-compiling each package' is not gonna get you a system with a new arch-specification. To really create an i686-slackware distro will require you to cross-compile a toolchain with which you can bootstrap into i686. Sorry, but you clearly don't know enough (yet) about toolchains to carry out this task (what on earth should the optimization level of binutils have to do with all this?). But keep hammering away and someday you'll 'get it'.

While creating a functional i686 toolchain, is relatively simple on i486 -> i686 (glibc, binutils, gcc), the big problem is the order of recompilation/rebuilding ... You know, THE DEPENDENCIES ... What are graceful "unknown" on Slackware ...

Right you are Darth Vader -even in the simplest of cases, everything must be re-compiled in a certain order, and some stuff has to be recompiled more than once. And, this is the simplest of cases, since there is forward binary-compatibility between i486 and i686 executables and libs, the job is much simpler than a 'real' cross-compile as most think of it. In fact, one could re-compile glibc for i686, but without changing the name of the target -I mean have an i686 system, but still having the compiler-related libs, etc under /usr/i486-slackware.