[Aboriginal] bootstrapping llvm

[Rob Landley]

On 10/04/2013 10:19:34 PM, Alain Toussaint wrote:
> > On 09/25/2013 02:45:03 PM, Alain Toussaint wrote:
> >> At the moment, I have built llvm 3.3 under gentoo with all the  
> targets enabled
> >> but tonight when I get back home, I'll try to build a  
> cross-compiler in my homedir.
> >
> > I note my record-command.sh and report-recorded-commands.sh scripts  
> (see the FAQ) are useful work working out build prerequisites.  
> They're available in the build on the host, and get installed into  
> the system images as a command line wrapper.
> >
> > Rob
> 
> Ok, I'll look into their sources. For the moment, I've been looking  
> at building
> llvm with musl using this page:  
> http://wiki.musl-libc.org/wiki/BuildingLLVM

Cool.

> I don't know yet if I'll follow the howto to the letter or adapt it  
> to use a llvm
> userland (the instruction refer to a libgcc & libstdc++ build and I  
> actually want
> to build with their clang/llvm counterpart) but I will decide later  
> next week.

The history of llvm involves creating a new code generation backend  
using the gcc frontend (llvm), then creating a new frontend (clang),  
then creating new libgcc and libstdc++, then creating a new assembler  
and linker, then fixing various packages that had upstream  
assumptions...

It's always been an incremental process to get to the desired result. I  
usually try to get something working then swap out parts one at a time  
with a known-good base to compare against. Once I get a knew known-good  
base, archive it and iterate with the next change. Often the first "get  
something working" is really crappy, from just "build it on my ubuntu  
host with their gcc and glibc and $PATH of tools" through "boot  
somebody else's image under qemu and poke around".

If you've played with Linux From Scratch, you'll see where I got the  
"populate a chroot with tools, then build another chroot using _that_  
chroot" approach. It's an excellent way to encapsulate your  
dependencies; if the first chroot is missing something it can't build  
the second. I'd make it work on x86 with just chroot, and _then_ worry  
about other targets and qemu. (You could even do actual linux from  
scratch using the gnu tools and then worry about swapping them out for  
busybox after you have a known working baseline. I doubt the llvm guys  
have been testing busybox/toybox as their build environment. :)

Rob
 1381008451.0