Slackware 12.1 but compiled -Os -march=pentium-m
Has anyone ever been able to compile Slackware "from scratch" so that it's -Os and -march=pentium-m?
I'd like to suggest that it may produce better performance on centrino laptops if compiled that way. If anyone is interested in doing so, I'd be willing to test it myself. As for Slackware itself, I'm surprised (with Patrick not enjoying how much fits on CDs/DVDs already) it didn't go -Os a while back. I tried compiling some stuff -Os and it was indeed smaller on disk, but that "rule" of 3% seems to mean that with -Os now your performance is 3% slower but it takes up 3% less disk space. Anyways, I'm just putting this out here for discussion. Also, does anyone know if Patrick has "special pricing" for how much a full recompile of Slackware 12.1 would cost if -Os and -march=pentium-m? |
Recompiling Slackware to whatever you wish is very easy with the SlackBuilds found under /source. Just enter your build options at the top of the file, and run the SlackBuild. At the end of the process, you have an installable Slackware package.
It is just time consuming to recompile everything. Most people don't feel the performance increase is worth the trouble, and if they do, they run Gentoo. As for fitting everything onto one disc, we are long past that point. Every release sees the addition of a dozen or more new packages, with no end in sight. Compiling the whole OS for size isn't going to save that much space. A better solution would probably be to increase the compression used in Slackware packages, but Patrick hasn't made any mention of making changes like that (presumably, he wants to avoid long install times on slower CPUs). Besides, now that DVDs are more prevalent, I don't think anyone is too upset about a full install not fitting onto a single CD anymore. |
Quote:
Can the compression actually be increased? Yeah, the DVD becoming common is making size considerations less important now. Even if you can't burn a DVD on a machine, normally you can still read one. Well thanks bro.... |
I am in the process of building a pure 64 bit (x86_64 -nocona) slack system from scratch, and it truly is a lot of work.
I have in the past tried the -Os switch, and am indifferent to the results. Much greater space savings to be had by brutally excising the documentation. |
Quote:
Say you start out with just the A and AP disk sets, which should give you a very minimal system. From there, just build the packages you actually plan on using; it would be much faster. To install it, the easiest option would be to partition a drive in two, install Slackware 12.1 (or -current) to one partition, and leave the other blank. Then, after you build enough packages, install them to the other partition using the "-root" option. Then you could set LILO up to dual boot between them, and hope for the best. "Easy" being subjective, of course. |
Just curious, you want to compile the whole slackware system on a centrino laptop ?
(if yes, maybe put a fan in front of it) |
"install them to the other partition using the "-root" option"
This doesn't work properly for glibc packages. AFAIK everything else works okay, but installing glibc using -root from your running system will create incorrect links when ldconfig is run. That is, it creates the links to the newly installed libs under the 'root' -it creates them on your running system, not under the new root. |
Quote:
As for CFLAGS, I recommend against using the -Os unless you know your version of gcc compiles programs correctly using this option. It usually does not improve performance too much either. If you want the best safe CFLAGS, get them here: http://gentoo-wiki.com/Safe_Cflags |
>> H_TeXMeX_H
"Why not just use slamd64" ? Call it pride and a sense of acomplishment to have done it all with my own scripts :} I have written a collection of scripts which I am tentatively calling "Slackware from Scratch" :) With willful revisions of the basic Slack scripts, occasional reference to LFS, some offline resources, and of course pkgtools, I have written a collection of scripts: each of which is intended to build an individual package, and, without alteration (in correct combination) build a toolchain type (bootable) environment. Althought I have written these for 64bit architectures, they should be easily adapted for 32bit. For my 64 bit builds I generally use: CFLAGS="-march=nocona -O2 -m64" with the occasional -fPIC thrown in to correct the seasoning. The gcc/binutils/glibc trio get flagged -O/-O0 - I would rather not trade precision for speed. So far I have seen no problems with this strategy. "/lib64" may have its place, but not on my systems. It is far more likely that I will consider including "/lib32" at some time in the future. For the time being, any 32bit apps I really think I need are living happily on my 32bit boxes. As far as I can see, multilib systems are transient and will eventually disappear as applications are updated to support pure 64bit environments. Why should I limit myself waiting for them? I am not unhappy ignoring such hardware and softwear as will not tolerate pure 64bit. There is always an alternative. |
Quote:
|
So let's see your Slack From Scratch scripts... there are calls for just such a thing from time to time.
|
Alternately, what I may try is doing a "linux from scratch" method, if I write down the order in which packages are built. Just a chroot install of Slackware A series, then rebuild from there, may work out for me. That or starting with busybox....
|
A basic starter, by no means definitive.
My own scripts will make more sense in context and should be available via ftp within the next couple of weeks, documentation later. I realize this proceedure may be more difficult on a system not already purged of frivillous dependancies, but with some effort it should work. I have begun with the basic framework laid out by the LFS team modified to use Slack tools. It will build a workable chroot but I had some problems with bootability (probably udev or a missing bootscript), which I have not yet had time to address. # ----- For each of these packages, modify the build script so that; BUILD=`date +%y%m%d%H%m` ${BUILD} now represents a dynamic value containing: year:month:day:hour:minute; (fixed at runtime) which allows each package to be upgraded without editing the script for each iteration. # ----- to create the chroot: CHROOT=/mnt/<xxxx> ROOT=${CHROOT} installpkg ${PACKAGE} I don't believe any of this will work with unedited slackware buildscripts. Any dependancy you allow here, will perpetuate and can eventually become annoying. If in doubt try applying the configure options laid out by the LFS people. Build then install as follows: # ----- noarch: aaa_base etc pkgtools # ----- kernel-headers gmp pass 1 mpfr pass 1 binutils pass 1 gcc pass 1 glibc pass 1 # tcl # expect # dejagnu ncurses bash bzip2 coreutils diffutils e2fsprogs file findutils gawk gettext grep gzip less # zlib # lynx make # glib # mc patch perl sed tar texinfo util-linux vim # ----- chroot Again, cribbed from the LFS people: CHROOT=/mnt/<xxxx> mount -v --bind /dev ${CHROOT}/dev mount -vt devpts devpts ${CHROOT}/dev/pts mount -vt proc proc ${CHROOT}/proc mount -vt sysfs sysfs ${CHROOT}/sys (umount these on exit) chroot "${CHROOT}" /usr/bin/env -i \ HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \ USER=root PATH=/bin:/usr/bin:/sbin:/usr/sbin \ /bin/bash --login +h # ----- In the chroot; build and install/upgradepkg, # ----- chroot gmp pass 2 mpfr pass 2 binutils pass 2 gcc pass 2 glibc pass 2 # yes I took another shortcut but should still be ok gmp pass 3 mpfr pass 3 binutils pass 3 gcc pass 3 berkeley DB sed e2fsprogs coreutils m4 bison ncurses procps psmisc procinfo libtool perl perl mods readline zlib autoconf automake bash bzip2 diffutils file findutils flex bin86 lilo # grub gawk gettext grep groff gzip inetutils # ipmask kbd less make man manpages module-init-tools patch procinfo shadow sysklogd sysvinit sysvinit-scripts tar texinfo udev util-linux vim # ----- |
All times are GMT -5. The time now is 08:21 AM. |