Re: trouble building cross gcc

["Kai Ruottu" <karuottu at mbnet dot fi>]

Robert Trask <rtrask@earthlink.net> wrote:

> Hello,
> I am trying to build a mips big-endian cross compiler hosted on a Linux 
> pc (Intel). I do the usual steps:
> # prefix is same given to binutils, previously built and installed
> mkdir build
> ../configure --target=mipsbe-linux-gnu 
> --prefix=/projects/san_engineering/santools/mipsbe
> make
> 
> The build terminates with an error partway through:
<snip>
> libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o libgcc/./unwind-sjlj.o 
> -lc && rm -f libgcc_s.so.1 && ln -s libgcc_s.so libgcc_s.so.1
> /projects/san_engineering/santools/mipsbe/mipsbe-linux-gnu/bin/ld: 
> cannot open crti.o: No such file or directory

 As you can see, the build tries to produce the shared libgcc_s.so and
symlink libgcc_s.so.1 to it... Create the '.so' first, then do the symlink,
in this order, so creating '.so.1' first, '.so' then, may cause creating the
'.so' tried again... One must mimic 'make' if required... 

 In the configure phase you could have used '--disable-shared' which
would have disabled producing these. But when you forgot to do this,
the workaround is to learn some basic skills... Like "how-to create
empty dummy files", 'libgcc_s.so' and 'libgcc_s.so.1' in this case.
When 'make' sees them being created there in the right order, it
doesn't try to create them any more and the build continues.

 For the basic skills any "How To Use Unix" book or course for newbies
should help ;-)  Okeydokey, the long one has worked, the easier it is to
forget those basic things... Sometimes I am very surprised to see that
knowing how to use 'touch' to create dummy files is so rare nowadays.

> I thought I would need the cross gcc to build the glibc.

 Yes, but you SHOULD have the Linux target headers, produced using
'make install-headers' for the glibc sources, plus manually copying the
'stdio_lim.h' (a bug maybe that the 'make ...' didn't install it) and the
dummy 'stubs.h' (the final one will be produced during the glibc build),
when starting to build GCC. Or you can try to get the Linux/MIPS headers
from somewhere else.  So this is some kind of "Catch-22" but the aim is
not anything like the "Unmarried Mother" from the "All You Zombies" in
the Heinlein's book.  The gal/guy there was both mother and father to
her/himself -- God save us from someone inventing the time-travel !
Methods like the one the Unmarried Mother used to get pure virgin genes,
should remain only in fiction...

> OR:
> do I need a crti.o in native obj format? I am confused. Any guidance you
> could provide would be greatly appreciated.

 This is the 'piece of cake' method, the same used in the native build: the
target C library is already there. It can be some old glibc for wrong CPU
type like a 'i386' library when producing tools for 'i686'.  Nobody hasn't
yet found a way to produce a native GCC on the native host without the
old C library (for creating the compiler executables and sevicing as the
'bootstrap' C library) being present, just believe me...

 If you get an old glibc for your 'mipsbe-linux-gnu' target, you will have
both the Linux headers and Linux libraries and can produce a complete
GCC with libiberty, static/shared libstdc++-v3, static/shared libgcc_s etc.
And all this already in the stage 1... Just as things would happen on the
native host.

 When GCC is ready, you can build your own glibc and then maybe rebuild
GCC against your own glibc. 'Maybe' because on the native Linux there
aren't so clear instructions about whether the GCC(s) should be rebuilt
after updating from glibc-2.3.1 to glibc-2.3.2 or something...  A careful
person probably does the rebuild always, but the majority probably don't
care so much...

 At least the Debian Linux sites have prebuilt (and probably 'acid tested')
glibcs for both 'mips-linux-gnu' (your 'mipsbe') and for 'mipsel-linux-gnu'.

 So what you want or don't want depends on your attitudes... The easy way
is to mimic the native GCC build, but you can also have the NIH-attitude
("Not Invented Here") and don't want to use anything others have built,
when 'bootstraping'. Then the question about the tools on the build host
becomes hard, they too can be built by 'others', can one allow this situation?
Should one first build them from their virgin sources? If the builds for the
native tools must be done by cross-compiling them on another host, must
one build all the tools there from their virgin sources too? And so on... The
truth is that every tool used with possible bugs can have its influence to
the result... Can a force transducer be calibrated with a precise force
thansducer? Or must one find a place where the gravity is well-known and
using known weights to give the known forces (doing the calibration in Mars
could fail miserably...). AARGH...

 I wouldn't care to start to think these things at all.  Just as I would trust a
stable and precise transducer in calibrations, I would trust some prebuilt
binaries in my builds...

 Ok, the Debian glibc packages weren't big, so my 'just for a fun' toolchains
for 'mips-linux-gnu' and 'mipsel-linux-gnu' were built with some Debian
glibc-2.2.5's from August 20, 2002 :
 
/home3/usr/local/mips-linux-gnu/lib > l crt*.o
-rw-r--r--    1 root     root         1931 Aug 20  2002 crt1.o
-rw-r--r--    1 root     root         2824 Aug 20  2002 crti.o
-rw-r--r--    1 root     root         2140 Aug 20  2002 crtn.o
/home3/usr/local/mips-linux-gnu/lib > l libc.a libc-2.2.5.so
-rwxr-xr-x    1 root     root      1695584 Aug 20  2002 libc-2.2.5.so
-rw-r--r--    1 root     root      3380376 Aug 20  2002 libc.a

 The whole 'mips*-linux-gnu' situation can be somehow unclear, people seem
to build native toolchains on their Linux/MIPS workstations almost daily but
who knows...  I remember there being problems in producing glibc from the
unpatched FSF sources, so using the Debian-patched and prebuilt glibcs was
not a hard choice.

 If I were you, I would spend more time with the Linux/MIPS sites hunting known
bugs, patches, fixed prebuilt glibcs etc.  And wouldn't care so much in reinventing
the wheel. If quoting the "All You Zombies", one of "The By-Laws of Time" describes
the "bootstrap" phase quite well: : "If At Last You Do Succeed, Never Try Again".
So when you have bootstraped once, never do it any more, just update components
in your toolchain when they require updating, fixing etc.  "Produce from scratch, Use,
Throw away, Produce from scratch,..." maybe describes the current way of life, but...
Some 'recycling', 'component reuse' etc. ideas could also be followed sometimes.
Things should only be made so well that they aren't considered rubbish when being
old...

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