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