Building on Fedora
Thu Sep 22 21:06:00 GMT 2005
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 :
> 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
Many thanks to all of you.
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to firstname.lastname@example.org
More information about the crossgcc