Before you Begin:
=================
This last time around I expiermented with '-march=core2' so that's what
all the PKGARCH variables will contain in base/. Do a find/xargs/sed
command to change them all if you're building for anything else... Watch
out for glibc and kernel build scripts. These should retain i*86 for x86.
Be aware, however, that the "base" scripts are the only ones to contain
a $PKGARCH variable. "Beyond base", all the build scripts get $PKGARCH
from /etc/bashrc so make sure you have booted into your new system
after you complete the base directory.
Also, recursively grep for "PLATFORM" in the source directories and
you'll see how I handle different arches.
Make sure you install a new kernel (and reboot) on the host before you
begin. Something that is close, if not exact, to what you'll be using for
your new system. As soon as we chroot, it won't matter what's on the host,
except for your running kernel.
A note on "7.1" or "8.0"... You'll notice the base, etc, network and
possible others have that type of version number. It's just an arbitrary
number I assigned because those are homebrewed packages. If this is your
first time building, change them to 1.0... Doesn't matter.
You'll want to extract the etc-$VERSION.tar.bz2 tarball and make
modifications to some or most of the files. Take your time and read
through every file. When you're done, package it back up. I've made that
package rather personal to my own setup.
Also, you'll want to recursively grep thru my scripts for the term 'jaguar'
and 'Jaguar'. Pick a name and then change them all. It used to be that I'd
have universal scripts for both Slackware and my DIY build (gnome). I needed
to implement a check for what OS I was building for, thus the reason for
/etc/jaguar-version. So, unless you want to call your new build "Jaguar",
you'll need to change all that. I also renamed some stuff in the pkgtool
scripts to use "Jaguar" and not "Slackware" via patch...
A note on CFLAGS usage, it's generally not a good idea to get overly crazy
with them. It's prudent to leave -O2 alone in $CONFIG_SITE. It's generally
OK to add machine specific optimizations but even this can be touch and go
at times. For scripts like glibc, we override and use -O3 but ocasionally
some packages (like an earlier binutils FSF) will crap out with -O3. If you're
taking the time to build from scratch, you'll want things to be as stable as
possible. It took me quite awhile to learn that. Don't fall into the
"gentoo" mentality of using insane and copious amounts of CFLAGS. You'll
wind up with a pile of garbage once you're done.
PKGTOOLS NOTE:
==============
I've just switched to pkgtools-13.0 which has support for multiple
compression formats. However, all my scripts are still hardwired to
use gzip (.tgz). Sometime soon, I'll modify all the build scripts to
use $COMPRESS instead of .tgz in the makepkg line. Then we can set
$COMPRESS in our ~/.bashrc for chroot and then in our /etc/bashrc for
beyond base... I'll figure something out within the next couple months.
Toolchain:
==========
Follow the "reference-build.html" file in this same directory.
When you get to the end, pick up below by running each build
script and then installing it with 'installpkg'.
Man-Pages
Linux-Kernel-Headers
Glibc
Readjust Toolchain
Zlib
Binutils
GCC
Sed
Pkg-config
Ncurses
Pkgtools
Util-linux-ng
E2fsprogs
Coreutils
Gawk
Findutils
Readline
Vim
M4
Bison
Less
Groff
Flex
Gettext
Berkeley-Database (db)
Network
Procps
Perl
Gzip
Texinfo
Grep
File
Libtool
Autoconf
Automake
Bash
Bzip2
Diffutils
Kbd
Man
Make
Module-Init-Tools
Patch
Psmisc
Shadow
Sysklogd
Sysvinit
Tar
mlocate
eject (from dvdcd in recommended. If on a Mac where you have no physical eject button, you'll need/want this)
dosfstools (if building bin86) (in extra)
bin86 (if building lilo) ( in extra)
Grub or Lilo (x86{_64})
yaboot (ppc) ** (in rest-stop)
mac-fdisk (ppc) ** (in rest-stop)
hfsutils (ppc) ** (in rest-stop)
reiserfsprogs (optional) ***
xfsprogs (optional) ***
jfsutils (optional)
Udev
Xz
which
linux kernel
Backup and then remove /temptools
** - I no longer have a ppc box so these should be considered unmaintained.
*** - I only use jfsutils so the other 2 don't see much love.
If you're going to reboot your computer at any time, make sure you rename
the new build's /etc/{bashrc,profile} to something else along with the new
build's /root/.bash{rc,_profile}. They will bork your chroot command when
you try to re-enter your build. To re-enter Do this:
source ~/.bash_profile (we created this at the begining of temptools)
run "Enter Chroot Environment" commands again and then "Perform Mounts".
If you need to do terminal work on the host, our ~/.bash{rc,_profile}
scripts from the toolchain section gives us a crippled shell. Do this:
source /etc/profile
===============
AFTER YOU'RE DONE
===============
Rename your new build's /etc/{bashrc,profile} back to original
along with your new build's /root/.bash{rc,_profile}. You should
also ditch /etc/config.site and ~/config.site on the host... Run
"pwconv" and then "grpconv" then "passwd" to set the root password.
Make sure your fstab is setup along with your bootloader.
tar up your /temptools for safe keeping and then do a:
rm -rf /temptools
Boot into your new System.
Once you have boot up, you can take off in any direction you
want, or you can follow the build order I use at:
http://jaguarlinux.com/pub/DIY/source/base-post-order.txt
Make sure you boot into your new system once done with the list
above. The "base" scripts are the only ones to contain the $PKGARCH
variable. With anything "beyond base", your shell needs to have
sourced /etc/bashrc for things to run smoothly...