1Building a cross compile tool chain is a serious pain in the neck. The
2main issue is that there is a circular dependency between gcc and
3libc. Because of this circular dependency, the build MUST proceed in
4the following order:
6 1. build binutils
7 2. build a subset of GCC that does not rely on access to libc
9 3. build libc using that GCC
10 4. build the production version of GCC
11 5. Set up some required symlinks for gcc.
13At each stage, the result of the previous stage must be installed
14before proceeding further.
16This sequence is painful, convoluted, and slow, but it is reliable.
18The symlinks part deals with the fact that the directory tree
19containing the cross compiler driver programs is not the target
20tree. The symlinks allow GCC to locate other components such as LD and
24Also a note on tree structure here. For packages that we take from
25third parties we want/need to keep the sources completely
26unchanged. For myself, I would *really* prefer to have them here in
27unpacked form. Unfortunately, the gcc configure process mungs the
28input tree even when it is built in a completely separate directory,
29and I have not (yet) found a way to repair that. Hmm. Perhaps cp -al
30would work. In any case, until we can deal with that cleanly we
31unfortunately need to check in the actual tarballs. So the tarballs
32in the SOURCES directory really are the official sources.
34For tools that we maintain ourselves we can make the configure process
35"clean", which leaves us the option to check them in as fully expanded
36trees. That is much more pleasant to maintain, but it means that the
37rpm construction process has to hand-build the tarballs for them. The
38ourtools/ tree contains tools of this form.
40Sigh. In this situation you simply can't win for losing.