This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building on Fedora


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]