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




Kai Ruottu wrote:
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...

We have very little flexibility around how we can develop and build code for our target device.


The target device is a STB with mipsel gcc-3.3.4 and glibc-2.3.2. I have zero control over the libraries on the device. The program we are trying to distribute to this device also needs to be really tiny, as there is limited space on the box. So, the best I can do is emulate the device environment by building (on x86) my own gcc-3.3.4 and glibc-2.3.2 for a mipsel target, and then see if the executables work on the device. I also can't distribute my own glibc to the box, as there simply isn't room enough on it -- I have to use the ones that are there currently.

In any case, it all works now, after modifying the glibc configure script to allow my x86 gcc 4.0.0 compiler to run, and also after figuring out the (unrelated) 60k padding problem (see below).

(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"....




If you see the "crosstool bloat" thread, you can see that we got this one working. It was a very simple one-line change in one of the shell scripts in the binutils package, which unsets DATA_ADDR. No more zero padding. :-)


Many thanks to all of you.

dk


------ 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]