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.

It's mainly what sequence to build those in that gets me. I wish he made his "build world" script available, but oh well. I was mainly interested in seeing if it was true (i.e. processors with lots of L2 "should" benefit from -Os), and trying a comparison.

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.

Well, you really only need to do the packages you will actually use.

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.

Why not just use slamd64 ? It's multilib, but you could just symlink lib to lib64 and you would have a pure 64 bit (not sure why you would deny yourself multilib).

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.

Well, I'd like to think so, but I don't. It really limits you not be able to use 32-bit apps that have not been ported yet. I'd like to keep that option open until nearly everything has been ported ... this is not that time, but when it comes I will also go pure 64.

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

# -----