Re: Building a cross-toolchain from scratch

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

Dan Kegel wrote:
> I wish I'd seen this before I updated Bill Gatliff's scripts to gcc-3.3;
> it looks like you ran into the same sort of things I did.
>
> ------------------- Begin nick's recipe --------------------------------
> The underlined term "from scratch" above refers to the fact that
> absolutely no sparc cross-development tools, no pre-compiled sparc
> system libraries, and no native sparc development environment, of any
> kind, are assumed already available. Apart from the host-native (ix86)
> tools, everything else will be built from sources. This is a very
> common case if the cross-toolchain is to be used for embedded-systems
> development.

 Please could someone explain in simple words what benefits this method
brings if compared to the "easy as a pie"-method for novices:

 1. Get the most up-to-date source releases for the tools

 2. Get a bootstrap-glibc for the target, for instance from the Debian
    archives, the glibc-2.3.1-17 seemed to be the most up-to-date there,
    for the 'sparc-linux' too.

 3. Build binutils and install it plus the prebuilt bootstrap-glibc

 4. Build GCC with all the extra libraries (libiberty, libstdc++)

 5. Build glibc from sources using the new complete GCC (if absolutely
    necessary)

 The result from this is a cross-toolchain built totally from virgin
sources, no prebuilt components are used in it (but used as tools during
the build -- using a hammer to produce a hammer should not be any worse
than produce a hammer with a stone-ax).  Generally all the native or
cross-tools for other hosts on the build platform should get the same
kind of 'traceability' consideration as the sources... If one starts to
track down the known bugs in the gcc-2.96 in RedHat 7.x or in the
gcc-3.x in RH 8.0 and 9.0, and tries to solve what these could cause
into the built binutils and GCC, when using these in the build, things
can become quite difficult...

 So my point was to ask about any documented cases where using a
prebuilt glibc in the 'from scratch' case had caused more troubles than
doing several iterations with the sources only...  It sounds weird that
anyone building GCC natively and using the old RedHat, Debian, SuSE etc.
provided glibc during the build, and then updating glibc with the new
GCC somehow are more probable to get a buggy GCC than those cross-GCC
builders building from sources. If this really is the case, all native
GCCs should be built without needing anything from '/usr/include',
'/lib' or '/usr/lib' during the build (only the old GCC used to produce
the compiler binaries could use them, not the new 'xgcc', 'cpp0', 'cc1'
etc. binaries...).  This far the host-GCC, host-binutils and the host
C library are considered to be 'traceable' and 'reliable' to work as
the bootstrap tools but these 'from scratch' methods in the cross-GCC
world try to put the host C libraries being somehow in suspect...

 Ok, somehow I suspect that the Debian 'glibc-2.3.1-17' could be more
bug-free than a 'glibc-2.3.2' built by oneself from the FSF-sources,
without any target specific extra patches, if looking at some specific
target. The '-17' could mean that the Debian people have tried to fix
at least something... Furthermore the Debian stuff is small, the shared
libs plus the static libs/startups/headers in the 'dev' package are
totally only about 6 Mbytes, sodownloading them takes only half-an-hour
on a 56 kbits/s modem line, much less time than building glibc from
sources would take on a slow PC... Although I had glibc-2.2.4 built
for 'mipsel-linux', and gcc-3.2.3 built with it, updating GCC to 3.3
and glibc to the 2.3-level, would be much easier if downloading the
glibc-2.3.1-17 from Debian and building gcc-3.3 with it, than building
glibc-2.3.2 with gcc-3.2.3 and then gcc-3.3 with glibc-2.3.2 and
possibly glibc-2.3.2 again with gcc-3.3...

 Okeydokey, here are short instructions for installing the
bootstrap-glibc from the Debian packages (and honouring the work of
the Debian people, not urinating upon their work, as the "very common
case", by Nick, could be):

 The following CPU architectures are supported with prebuilt
glibc-2.1.3, 2.2.5 or 2.3.1 on the Debian archives:

	alpha, arm, hppa, i386, ia64, m68k, mips, mipsel,
	powerpc, s390, s390x, sparc, sparc64

 The packages for the runtime shared libs and the 'dev' one could
provide the minimal set if aiming to update glibc after the GCC
build. So for instance the following packages would provide the
bootstrap-glibc for Linux/PPC:

 libc6-dev_2.3.1-17_powerpc.deb 2874 KB 20.4.2003 22:17:00
 libc6_2.3.1-17_powerpc.deb     3817 KB 20.4.2003 22:17:00

 The Debian packages are archived with 'ar', so using:

	ar xv <filename>.deb

will unpack the package into the current directory. Then
using 'tar xvzf data.tar.gz' for the data itself will unpack
the stuff into 'lib', 'usr/lib', 'usr/include' etc. in the
current directory. Please note that the name is always the
same 'data.tar.gz' in every package, so handling them one by
one with 'ar' and 'tar' will be required. After unpacking
all the needed packages, the 'lib', 'usr' etc. stuff can be
moved into the final chosen $prefix/$target/lib and
$prefix/$target/include.

 The following script fixes the symlinks between the original
'native' glibc files:

---------------- clip -----------------------------------
ln -f -s libanl.so.1 libanl.so
ln -f -s libBrokenLocale.so.1 libBrokenLocale.so
ln -f -s libcrypt.so.1 libcrypt.so
ln -f -s libdl.so.2 libdl.so
ln -f -s libm.so.6 libm.so
ln -f -s libnsl.so.1 libnsl.so
ln -f -s libnss_compat.so.2 libnss_compat.so
ln -f -s libnss_dns.so.2 libnss_dns.so
ln -f -s libnss_files.so.2 libnss_files.so
ln -f -s libnss_hesiod.so.2 libnss_hesiod.so
ln -f -s libnss_nisplus.so.2 libnss_nisplus.so
ln -f -s libnss_nis.so.2 libnss_nis.so
ln -f -s libpthread.so.0 libpthread.so
ln -f -s libresolv.so.2 libresolv.so
ln -f -s librt.so.1 librt.so
ln -f -s libutil.so.1 libutil.so
---------------- clip -----------------------------------

 The 'libc.so' script in the libraries should be edited to
be something like (ie. the absolute paths stripped away):

---------------- clip -----------------------------------
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( libc.so.6 libc_nonshared.a )
---------------- clip -----------------------------------

 I tried the 'hppa-linux' target with the Debian glibc-2.3.1-17
and got the toolchain without any problems...

 Those who are absolute dummies can also consider downloading a
prebuilt embedded Linux-target toolchain. The Wolfgang Denk's
company site, 'Denx', could be one place to find toolchains for
PowerPC, ARM and MIPS targets, their "Embedded Linux Development
Kit" (ELDK) provides these:

   http://www.denx.de/re/ELDK.html

 If needing a car, one could consider buying a car or finding
out where one can find one as free, not necessarily seeing building
the car being the only choice...

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