Building on Fedora

[Kai Ruottu]

David Karlton wrote:
> 
>>> I'm trying to build crosstool-0.38 on a number of linux installation 
>>> (Suse 9.1, Fedora Core 2), and am having trouble with Fedora.  

  So your goal is NOT getting a toolchain, but to get it built on
number of linux installations and from scratch as if your target
wouldn't yet exist and so there being nothing for that yet?

> Thanks for the input.  I am stuck with glibc-2.3.2, unfortunately (I'm 
> building to a target device that I don't have control over).

  If your goal would be getting a crosstoolchain for your target
device, then you wouldn't try to build its original (custom?) C
libraries again, or how?  Just use them 'as is' in your crosstools...

  And if your goal is not to experiment with possible binary
incompatabilities, different libraries used during link-time
than used at run-time, using the originals makes sure about
100 % compatability between link-time and run-time, what becomes
to the libraries used. Using a different GCC than used to produce
the run-time of course can have its influence, but native GCC
users update their GCCs all the time and this is not seen being
a big problem, besides with C++. (I remember asking sometimes
whether the 'libstdc++.so.5' coming from the g++-3.3.x build is
backwards compatible with apps made with g++-3.2.x and needing
the same named 'libstdc++.so.5' at run-time. But not seeing any
answer.) Native link-time and run-time target libraries are not
replaced in a native GCC build, so they shouldn't be replaced
when producing another incarnation of the target tools on another
host !

  If you produce gcc-3.3.x as the cross-GCC and the target
has its runtime built with gcc-3.2.x, and then replace the
original '/usr/lib/libstdc++.so.5' (I remember this being in
'/usr/lib') with the one got with the cross-GCC, could the old
C++ apps continue to run?  What if the old 'libstdc++.so.5'
will be keeped, do the new g++-3.3.x made C++ apps run with the
old runtime C++ library? The C++ world is much more complicated
than the simple C world.

  My thought is that you should think thoose compatability things
before going to replace essential parts in your crosstools with
self-built components (glibc-2.3.2, libtermcap, libncurses, X11
libs,...), which you seem now doing...

> (Now I just need to figure out why the cross-compiler pads everything I 
> compile with 60k of dead air.)

  The references Dave Korn showed, should tell this being the goal
in Linux/MIPS, it behaving like Unix SVR4/MIPS and being compliant,
compatible, conformant or something told with a fine word, with its
SVR4 ABI. Please see :

   http://www.caldera.com/developers/devspecs

and download that "MIPS® RISC Processor Supplement 3rd Edition" PDF
document. I think it should tell those alignments to 64 k boundaries.

  The old 12 bit / 4 k alignment seemingly was broken/wrong all the
time. But a check with the 'current' NetBSD/MIPS (evbmips) Ver.2.0.2
told that it still uses the old/broken (non-ABI) alignments...

  I really don't know what segments will be aligned and for what purpose
that 60+ kbyte gap is, but I would expect it being filled in larger
apps than the "Hello World"....

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