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...