Re: Generating a Cross Compiler entirely from source

[Kai Ruottu <kai dot ruottu at luukku dot com>]

David Dudley wrote:
> 
> Well, I'm in the same situation that a few of the others on this list are in.

 Hmmm, if 'reinventing the wheel' is really the goal here, then the situation may
be this...
 
> I need to generate a cross compiler chain, entirely from source.  The contract
> I'm working from requires me to provide this capability, if it exists.

 Is it allowed to produce a hammer using another hammer ?  Or must one still use
only a stone when doing the first hammer from metal ?

 So the 'contract' would also stupidly require the native compiler and the native
C-library and the whole native opsys also being produced from the sources ?  And
all the native tools, of course...

 But probably the question is about the possibility to 'produce entirely from source',
just as one can update GCC and glibc completely from their sources in the 'native'
situation.

 But, perhaps it is always expected one to remove the old native glibc before the GCC
build, because the new GCC build would then be done against the old glibc, not against
the needed new one!  But when then no executables could be produced without the existing
C-library, the GCC-build would be impossible and the job must be done on another system
by cross-building there. But the 'contract' may require that no prebuilt stuff should
be used either there...

 My opinion is that the cross-GCC build shouldn't be any different from the native-GCC
build, some 'bootstrap glibc' for the target GCC already existing and the new GCC will
first be built against it...

 When GCC is ready, it can be used to update glibc... And ONLY IF glibc can be built
using it. One can build a up-to-date GCC because the new version has better C++ properties,
not because wanting to build Linux-kernels and glibcs with a 'rock-solid', time-proven
GCC like egcs-1.1.2 or gcc-2.95.x...

 The situation with gcc-3.0.4 is still mostly unclear... When gcc-3.0 appeared, it
was widely known that glibc couldn't be built error-free using it. But whether the newest
'bugfix-release', 'gcc-3.0.4' is capable to do this, with the 'x86' target is unknown
at least to me....

> Heres the situation.
> 1. My host is a <sparc-linux-gnu>.  The target is <i386-pc-linux-gnu>.
> 
> 2. I unarchive a source package for the Linux dist - 2.4.17.  I can do a
> configure with no problem, and then copy the include directories over to my
> target disk, in the right location.  No problem there.

 Whether the linux-2.4.17 kernel can be compiled (ie. it works) using gcc-3.0.4
is another thing to check...

> 3. I generate the binutils (latest CVS pull) with no problem.  These work
> fine, and install with no problem on my target disk.
> 
> 4. I unpack the glibc package (2.2.5) and generate a <make dep> OK.  I then
> install <make install-headers>, and it copies all the headers into the right
> places on the target.  Still no problem.
> 5. I unpack gcc (3.0.4), and configure it for generating a cross compiler.

 As told, the situation with using gcc-3.0.4 to compile the glibc-2.2.5 sources
must be checked from somewhere (like 'http://www.gnu.org')
 
> Things are still going great.   I do a "make all-gcc" on this, and the <xgcc>
> program is created OK.  It even works.  However, then it starts cross
> compiling the runtime library, and things fail with pages full of errors,
> which basically amount to a missing file, <features.h>.  This file is created
> by the compiler, I think, when the compiler is installed.  But if I don't
> have a compiler yet, how do I generate it?

 As with building the native GCC, the prebuilt C-library (glibc-2.x.y) for the
target is expected to exist and being installed at the same time with the target
binutils. If the target would be Solaris2.6 or something else with 'proprietary'
headers and libs, nobody probably would argue about the necessity to preinstall
the target binutils, libs and headers before the cross-GCC build.

 But all the Linuxes as cross-targets seem to be hard cases. The 'NIH-attitude'
("Not Invented Here"), or "Everything which someone else has built, must be pure
garbage, only I have the needed know-how to build it right!" can easily be seen.
Ok, I can only confess sharing this same attitude ;-)

 If I would build those glibcs for the Linux-distributions, first I would leave the
debug info away from them, in order to give the influence about them being 'rock-solid',
'acid-tested' and 'high-quality production-grade' libraries, not "something full of
bugs which the user must absolutely first debug"... Just please see the 20+ Megabyte
'libc.a' and the 5+ Megabyte 'libc.so.6' in the RedHat-distributions... Ok, the CPUs
are now quicker, disks are bigger, so it perhaps doesn't matter if reading from a 20+
Mbyte file takes a little longer than from a 2 Mbyte one, or if the library install
takes 100 Mbytes of disk space instead of only 10 Mbytes...

 Using the 'strip --strip-debug' for the '.a's doesn't sound bad, but doing the same
for the native run-time '.so's may need a little more courage... For cross-target
libs this isn't so bad, only downloading mostly unnecessary stuff takes too much
net bandwidth...

 Secondly I would pack the glibcs also into tarballs, not into the current 'rpm's only...
Definitely also us cross-GCC builders could need those 'production-grade' tested libs.
I maybe am stupid and lazy, but I really don't know any other means for unpacking those
'.rpm's in alien platform than converting them into '.cpio's using 'rpm2cpio'. Maybe the
new 'rpm'-installers allow anything to be unpackaged to anywhere and trusting the user
knowing what one is doing, but the older ones didn't trust the user at all... Anyway
forcing one to experiment with all those 'RedCarpet's etc. 'install' programs instead of
simply unpacking a tarball is a nuisance...

 Ok, basically there also aren't anything like 'i386-pc-linux-gnu', if one thinks about the
Linux-distributions, only 'RedHat 6.x', 'RedHat 7.x', 'Mandrake', 'SuSE', 'Debian' etc.
And no sure info about any 'binary compatability' between them. A self-built embedded
Linux-board could have a 'Linux' named like this... Or a 'generic Linux/x86' target if
one trusts the produced binaries running on all those RedHats, SuSEs, Mandrakes and
Debians... Optimistic one can be, but not too much, so the possibility to need separate
tools for 'i386-redhat-linux' than for 'i586-suse-linux' can be a possibility... So I
would be worried about whether the produced binaries will run on the target system (if
it is a 'system'). Or if any 'compatability with 'Linux-distribution-X' would be needed
(The end user copying a prebuilt Linux/x86 executable from a PC with SuSE 7.3 into an
'embedded' Linux/x86 system and the program not working there...).

 So I would suggest using any prebuilt glibc for the target in the 'bootstrap' stage
for GCC, then update the glibc if necessary and then rebuild GCC with the new glibc, if
necessary... Just as if working with the native GCC and native glibc on a Linux-system.

 Updating only GCC (or building a cross-GCC) to use some existing glibc, or updating only
glibc using the existing GCC, seem to be the expected cases currently in the GNU sources.
Of course one could wish that producing first GCC from sources, then the C-library from
the sources could be easy as a pie, but the current expectation about a native build with
all the 'system targets' doesn't make this easy. So behaving like building in the native
environment helps things a lot...

 Basically extracting the glibc-headers from the glibc-sources and preinstalling them
should be possible. Then building GCC without a real 'libgcc_s.so.1' : the 'make all-gcc'
will be happy when only seeing this and the 'libgcc_s.so' in the $build/gcc... Answering
to the question: "How to create empty files on the Unix-environment?" will however be left
as homework for all the Unix-newbies... The same kind of situation may come with the glibc
build: when the error message about 'linux/autoconf.h' comes, one can consider to configure
and build the Linux-kernel for the target, and sweat a lot when doing this... Or to give
'make' or to the requesting header what it wants, the requested file... It will be that
nothing will be needed from it, so it can be empty. Or the info about what will be needed
from it will be seen...

 And GCC and glibc can normally be built in parallel... The 'csu' (C Start-Up) subdir will
be built quite soon in the glibc-build and the needed 'crt1.o', 'crti.o' and 'crtn.o' will
be produced for the 'libgcc_s.so' build in GCC, but maybe the 'libc' would also be needed.
Maybe the 'libgcc.a' is enough for linking the 'libc.so.6' in the glibc-build, and the
'libgcc_s.so' can be built only after getting the 'libc.so.6' from the glibc-build... Or
the situations have now been changed... One sees when one tries.

 Capability to think only simple thoughts is recommended, one doesn't need a MSc or PhD from
MIT, UCSD, Stanford or something (in my case HUT), although it may help in thinking simply
enough... Knowing how GCC and glibc work is preferred, knowing how to port GCC for a new CPU
or how to fix functions in glibc will not be needed.
 
 Anyway all this is too complicated if the possibility to get some glibc for the GCC build
exists... Hating those big 10 + 10 Megabytes (run-time + development) RPMs with their
'undebugged binaries' and generally having the NIH-attitude may be a good reason for all
this pain, but when there is an easier way, why not try it first... My first cross-GCC for
Linux'es was for the 'powerpc-linux' and then I used the glibc-2.0.x-something from the
'Yellowdog' Linux/PPC-distribution, when not yet knowing clearly what I was doing, but have
later done many other GCCs with glibcs using the 'hard way', because downloading 20+ Megabytes
using a modem isn't a big fun, and because already having the glibc-sources... And of course
not having any hurry or a need for any 'being productive'-nonsense...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com