###################################################################### # Document: armedslack-current/ARMedslack_Notes/Source_build_order.txt # Purpose : Try to document how I built ARMedSlack from # scratch. My memory's hazey though so I can't # remember, but when it comes back to me, I add it # in here for future reference and interest. # Author..: Stuart Winter # Date....: 01-Jun-2004 ###################################################################### It's worth noting that because I used Scratchbox (http://www.scratchbox.org) for the intial porting (and I still use it but to a lesser degree now, due to technical reasons), I didn't need to build tools such as: makeinfo perl groff gawk gcc and many other doctools. This helped enourmously in speeding up the porting of Slackware. Order: ------ 1. zlib - glibc relies on it 2. glibc Built as many libraries from the l/ series as I could Built as many development programs from the d/ series as I could Built as many apps from the a/ series as I could I eventually had to abandon scratchbox for building many of the packages because it: [a] Sometimes scratchbox's paths (e.g. /scratchbox/tools/bin/blah) were being hard coded into the binaries/scripts [b] I started (31-May-2004) building everything with gcc 3.4 natively on ARM (mostly due to [a]). Scratchbox has gcc 3.3 and since I didn't feel like making an ARM gcc-3.3 package, it meant that I didn't have my own version of the gcc-g++-3.3 support library to package up. (I couldn't steal Scratchbox's because it won't work correctly on the RiscPC). [c] Scratchbox's default build arch is xscale (I think) and I could not (with sb-0.9.7) make its gcc honour the specs file so that it would build for armv3. lle (the SB toolchain guy) made a script to build a toolchain for SB *inside* SB, but this soon broke. This meant that to avoid producing binaries that would break on a RiscPC, I had to hack in -march=armv3 into CFLAGS -- this becomes time consuming for many applications that don't have configure scripts. Therefore it was ultimately easier to just build natively -- at least that way it's guaranteed to work because I built the compiler :-) I can't remember anything else atm. Present build system -------------------- What I tend to do these days is: [a] Update/edit/write the script script [b] Test it inside scratchbox to ensure it compiles and that I haven't made a typo in the build script (spending an hour compiling on the RPC to find I've made a fatal typo that prevents the package being built correctly would be a real nuisance) [c] Build natively How did I get here? ------------------- 1. I compiled dpkg-deb on Slackware 2. I brute force installed Debian ARM onto a hard disk 3. Stole some files from a friend's netwinder (running Debian ARM) and copied them onto my hard disk. 4. Booted it on the RiscPC. 5. Installed Scratchbox 0.9.7 6. Configured SB for CPU transparency - ran sbrshd on the RiscPC running Debian At this point the machine was frequently falling over because the entire OS was held together with scotch tape; I couldn't install Debian properly because the installer was broken and I hadn't heard of debootstrap at the time. 7. Started writing the preliminary build system for ARMedSlack and built the base packages. 8. Build a stage 1 ARMedSlack installation and watched it fail miserably on the RiscPC. The first boot was total failure. 9. I found out that it was because my binaries had half word instructions compiled into them which do very odd things on the RiscPC. 10. Rebuilt packages with -march=armv3 and tried again. It worked! 11. Dumped Debian and booted into ARMedSlack. 12. Continued building inside Scratchbox for a while. 13. Scratchbox 0.9.8-rc1 was released which allowed the use of qemu (an arch emulator). This allowed me to build gcc & binutils inside Scratchbox. 14. Started building natively on the RiscPC/ARMedSlack.