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: Resulting files from canadian cross


On Mar 08, 2007 07:03 PM, Kai Ruottu <karuottu@mbnet.fi> wrote:

> The same thing can happen with "crosstool" only after the whole target
> system is
> created with the crosscompiler which crosstool produces :-( So why you
> choosed
> to use it and not created a fully normal crosscompiler for your
> target?

Because I've been trying for weeks to do it "manually" and kept failing,
and there was no documentation to be found that helped me sort out the
various compiler errors etc. (And I didn't know about this list until I
found crosstool). :) With crosstool, the crosscompiler was created in
one go, and the native arm compiler took a few attempts (some version
conflicts, but at least they were easier to solve since the setup
scripts eliminate a lot of incompatble combinations of gcc/glibc in
advance and also take care of the compiler switches needed to get things
work that I can't even begin to comprehend, again for total lack of
clear howtos on this particular subject).

> If you would have produced a normal crosscompiler, it would be
> probably
> made in the
> previous way, keeping the $host and $target stuff separated!

Ok, then I guess what crosstool tried to do was create the arm-compiled
host stuff on /opt/arm/gcc.../arm-unknown-linux-gnu and the stuff that
was meant to go to the target on
/opt/arm/gcc.../arm-unknown-linux-gnu/arm-unknown-linux-gnu. The strange
thing is that it doesn't appear to be enough to export only this target
directory to the arm system.

Your explanation did already make things clearer for me, though not yet
clear enough for me to either do this manually after all OR understand
crosstool's result layout - then again it seems crosstool confuses you
as much as it does me. ;o)

There is an option "USE_SYSROOT", but when I enabled that, it got even
worse; I got THREE incomplete usr-structures instead of two. :o)

Is there anybody here who knows how crosstool is meant to be used in
this case? I find it hard to believe that such a well-considered set of
scripts that solves so many dependancies and chicken-and-egg-problems
(including chicken incompatible with their eggs) leaves such a mess in
the end. :o)

Now, a very concrete question: I saw a link on the crosstool howto to a
thread on this list about making a native compiler, and there the
solution to someone's problem (resembling one of the ones I found during
my various tries) :) was to set CROSS_COMPILE to 0 in the gcc specs
file. Indeed it's set to 1 in mine, so even when I'm building the native
ARM compiler, gcc thinks it's buiding a cross compiler. Apparantly this
has to be 0 before building the native compiler, but how do I do that
when the specs file is generated during the build? (Sorry, gcc noob in
case you didn't notice) :o)

Maurits.



--
For unsubscribe information see http://sourceware.org/lists.html#faq


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