Re: "What are you doing with crtstuff.c" on gcc-3.4.0 arm build

[Toralf Lund <toralf at procaptura dot com>]

>  [ ... ]


> Maybe not so many building for the
> ARM/COFF format any more and therefore no problems seen earlier on the
> crossgcc list.

I thought it made more sense to use COFF when you don't require the 
additional features offered by ELF, which you don't with the kind of 
"minimal" setups often discussed on the crossgcc list, but maybe 
everyone disagrees with me and are using ELF after all, or perhaps not 
that many people cross compile in the first place...

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

I'm not sure that's only something a novice would do, unless you're 
limiting the term to experience in building gcc for different setups. In 
general, experience teaches you not to reinvent the wheel and not try to 
fix something that works, I think...

Also, the GCC manual isn't really that specific about gross compilation, 
at least not the online install doc, which was where I looked before I 
found the crossgcc list etc. It did point me in the direction of the 
list, though...

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

Yes, definitely. If some step is considered to be a workaround, clearly 
it ought to be documented as such.

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

I'm actually using that option. However, when I tried to find out some 
time ago what it did, I found that it wasn't even indented to guarantee 
that GCC could be built in one step when using newlib - all it was 
supposed to do was to cause one or two functions to be omitted from 
libgcc.a.

>  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

Quite. That's exactly what I've been doing - after configuring with 
--with-newlib, --enable-languages=c and --without-headers

But actually, I've used good old version 2.95.3 so far. The reason being 
that some old code (which I'm trying to clean up, of course) was a lot 
easier to compile with that release because it is less pedantic than 
version 3, and also that someone on the list mentioned serious issues 
with older gcc 3 releases on the ARM platform. - Or perhaps it was on 
MC68K, which I also build the same code for (and I prefer to use the 
same compiler version on both platforms)...

> [ .. ]
>
>  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,

Yeah, you'd think that it should do exactly the opposite.

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

The FAQ includes "--build-new-lib" in stage 1, but *not* for the final 
build.

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

Yes. Personally, I tend to report bugs, *then* create workarounds... I 
haven't registered any issues for gcc yet, though... But like I said, I 
think maybe the problem is that the gcc install guide doesn't say very 
much about building cross compilers at all - and the alternative FAQ it 
points to is even older than the Bill Gatliff one. But of course, this 
may be considered a (documentation) bug, too...

> [ ... ]
>  
>
>  Generally I don't use any "build tool"s (premade scripts from 
> others), but will

Neither do I. Except for rpmbuild, that is... Yep, I'm building my own 
rpm packages for the cross compiler, like I do for just about everything 
else I can't find pre-built. Installing directly to the target with 
'make' is generally a bad idea, I think, as you loose control over 
what's really installed on your system after about 3 products (or I do, 
anyway)...

The %install section of the rpm spec is also a build script, of course, 
but I've written it myself, although it borrows heavily from the FAQ and 
accompanying build script.

Perhaps I'll try to update the commands so that it uses your header file 
hacks + a direct build instead of the two-stage approach... There are 
special issues I need to keep in mind, though, like the fact that I have 
to execute gcc from a special build tree during the newlib build (which 
is not a problem with the current setup, since I can configure the 
"core" version of gcc, which won't be included in the package, with that 
tree as install *and* execute prefix.)

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

Yes, something like that.

> [ ... ]
>
>  Therefore I would rather see a name like "stub-GCC" or "stripped-GCC" 
> used
> for a not-so-complete GCC,

Yes, I probably shouldn't have used the term "bootstrap" (and neither 
should the FAQ) as it really means something quite specific and 
different from what we are talking about here, in the GCC world.

> [ ... ]
>  Bootstrap components and tools are those prebuilt ones to workaround the
> Catch-22 or chicken-and-egg situations,

This *is* in a way the situation with gcc + newlib, in the sense that 
newlib clearly requires gcc and gcc requires newlib, although perhaps 
not for the actual C compiler, or in a way that requires newlib to be 
fully built. Also, your newlib header install phase might perhaps be 
called a bootstrap newlib installation...

- Toralf


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com