Re: How to solve the relationship between gcc and glibc when building cross compiler toolchain?

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

2.7.2015, 0:59, Matthew Fortune kirjoitti:
> jpcstpj7281 <jpcstpj7281@126.com> writes:
> > Recently, I've tried to build a cross compiler toolchain for MIPS architecture.
> >
> > But when building the bootstrap gcc with the following configuration and command, it got a
> > error message:
> > The gcc-bootstrap error message is:
> >
> > .../tools/mips-linux/bin/ld: cannot find crti.o
> > .../tools/mips-linux/bin/ld: cannot find -lc
> > .../tools/mips-linux/bin/ld: cannot find crtn.o
> > collect2: error: ld return 1
> > make[2]: *** [libgcc_s.so] error 1
> > Once I change the configuration --enable-shared to --disable-shared, the gcc-bootstrap
> > will build successfully.
> > And then, when I build glibc using the previous gcc-bootstrap with the following command,
> > it get a error message:
> >
> > The glibc error message is:
> >
> > .../tools/mips-linux/bin/ld: cannot find -lgcc_s
> > collect2: error: ld returned 1 exit status
> > As shown above, the gcc-bootstrap compilation with configuration --enable-shared in order
> > to build libgcc_s.so needs the file such as crti.o and crtn.o that glibc builds. Once
> > changing to --disable-shared, the gcc-bootstrap build successfully and will not build
> > libgcc_s.so file. However, when building the glibc, it needs libgcc_s.so file to link. Can
> > anyone tell me how to solve the relationship between gcc and glibc as above?
> I'm not sure I've been much use as these chicken and egg problems drive me crazy for ages
> then I solve them and promptly forget how.

There are similar "Catch 22" situations in the world. For instance when 
buying a car, it may have "wrong" brand tyres or when buying a PC it may 
have "wrong" opsys (DOS, Windoze).  But without these "wrong" things the 
bootstrap with the thing : car, PC etc, can be hard...

So when the GCC build for a "system target" needs an existing target C 
library because the default GCC type for it is the "native GCC", and the 
glibc build also expects a "native" build : upgrading the current 
runtimes and development libraries & headers, it is much easier to not 
have that "only everything from scratch is allowed" attitude.

For the 'mips*-linux-gnu' there are at least those Debian's prebuilt 
glibcs which are "compatible and suitable" to serve as the equivalents 
of the "wrong" tyres, opsyses etc. which are usually the easy way to let 
one to drive to a tyre shop or download the "right" Linux distro and 
burn it into a DVD...

For instance :
ftp://ftp.funet.fi/pub/linux/mirrors/debian/pool/main/e/eglibc/libc-bin_2.13-38+deb7u8_mips.deb
ftp://ftp.funet.fi/pub/linux/mirrors/debian/pool/main/e/eglibc/libc6-dev_2.13-38+deb7u8_mips.deb
(big endian) and :
ftp://ftp.funet.fi/pub/linux/mirrors/debian/pool/main/e/eglibc/libc-bin_2.13-38+deb7u8_mipsel.deb
ftp://ftp.funet.fi/pub/linux/mirrors/debian/pool/main/e/eglibc/libc6-dev_2.13-38+deb7u8_mipsel.deb
(little endian) for the 32-bit MIPS as the "base headers & libs" packages.

For many "just for a fun" builders making crosstoolchains for 
'mips*-debian-linux.gnu' would happen with this way, not building the 
glibcs at all but using the original Debian ones.  If one really wants 
the target to be "my own Linux distro", then building an own glibc with 
the already working "complete" GCC (for Debian) is always possible.  And 
after the self-made glibc is ready and installed, the situation is just 
the same in the beginning of the "newer" GCC build :  There is that 
"wrong" old glibc for the target needing also updating after the newer 
GCC is ready and working - with the old self-made glibc.  No need to go 
back to that "from scratch" method with iterations using "brain damaged" 
GCCs (without a shared libgcc)...