2.7.2015, 0:59, Matthew Fortune kirjoitti:
jpcstpj7281 <jpcstpj7281@xxxxxxx> 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)...
