This is the mail archive of the crossgcc@sources.redhat.com 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] |
[ ... ]
Maybe not so many building for the ARM/COFF format any more and therefore no problems seen earlier on the crossgcc list.
parts defined needed meanwhile the '.../t-xscale-coff' doesn't... So it seems to be a plain vanilla bug in GCC since gcc-3.3...
I get this when trying to build gcc-3.4.0 for arm-coff, during the "bootstrap compiler" step.
Please explain this 'bootstrap'... Building an 'arm-coff' targeted GCC needs only one stage, just as any normal cross-GCC,
That's new to me. Isn't the consensus here that you have to
Not at all, novices simply do just as they are instructed in those FAQs, without reading any original docs from the GCC manual
But in those FAQs there always should be told how the job SHOULD work when all the known bugs are fixed, and how the job used to work before the new bugs became into the sources...
[ ... ]
2. Build a C-compiler with which you can build newlib, specifically a minimal gcc setup; you can't create a full gcc as that actually requires an implementation of libc
Wrong, the '--with-newlib' should take care about that a complete GCC can be
Ok, with gcc-3.0.x etc. which had bugs in the '--with-newlib' issue, producing
only GCC (with all the compilers, C & C++, which a newlib-based GCC could have,
don't know about Java etc.), would have been the stage1, "make all-gcc" did
[ .. ]
Usually I have always some extra patches added into my gcc-3.2.x, gcc-3.3.x and
gcc-3.4.x sources and therefore the builds could succeed better than from the
plain vanilla FSF sources, so I was surprised to see the plain vanilla gcc-3.3.3
sources trying to produce 'asprintf.o' and 'vasprintf.o' into libiberty although
these are already in newlib... If the previous clip means that those functions
should be produced into libiberty when using newlib, then here is a bug,
Bugs like the previous will go unnoticed if people don't use '--with-newlib' in
their configures, and don't try to build a complete GCC in the stage 1 but ...
[ ... ]
So in my build model people should check the ways things should work, not being
pessimists and using workarounds because "nobody will ever fix these features",
and then never reporting those bugs...
[ ... ]
Generally I don't use any "build tool"s (premade scripts from others), but will
Maybe you meaned that you must first update your native GCC or the cross
GCC used to produce the GCC binaries. This can be called as the "bootstrap compiler" step.
The "Prerequisites" in the gcc-3.4.0 "Installing GCC" manual should describe
the term "bootstrap compiler", like :
-------------------------------- clip ---------------------------------------
Tools/packages necessary for building GCC
ISO C90 compiler
Necessary to bootstrap the GCC package, although versions of GCC prior to
3.4 also allow bootstrapping with a traditional (K&R) C compiler.
To make all languages in a cross-compiler or other configuration where 3-stage
bootstrap is not performed, you need to start with an existing GCC binary
(version 2.95 or later) because source code for language frontends other than C
might use GCC extensions.
-------------------------------- clip ---------------------------------------
[ ... ]
Therefore I would rather see a name like "stub-GCC" or "stripped-GCC" used
for a not-so-complete GCC,
[ ... ] Bootstrap components and tools are those prebuilt ones to workaround the Catch-22 or chicken-and-egg situations,
------ 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] |