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]

Re: Work on new CrossGCC FAQ underway


Michael:


> Since we are building cross-GCC for a number of targets, we want
> to build each target in exactly the same way, not with a different 
> recipe for each target.  For the most part, we are able to do this.  

Until there is more standardization between ports, a consistent recipe
won't exist.  But honestly, the variations so far have been pretty
simple.  It hasn't seemed like a matrix problem so far, to use your
term.

I think a lot of people's problems in building are actually with
build/host machine configuration issues, not the build process itself.
My build script does little to help in this department, short of
fixing the obvious things like having write access to the installation
directory, having the tools in the path during building, and getting
--prefix and --with-local-prefix set consistently.

> I have built GCC using Cygwin in the past, but not recently, so I'm
> not current on the differences with build on pc-linux.  

I'm preparing to attack that problem myself-- I'm getting a Cygwin
setup here shortly (I'm all-Linux at the moment).

> One problem I see with the matrix approach (one entry for each
> host/target combination) is that the descriptions diverge.
> Differences between targets get described as if they are SOP, rather
> than undesirable, and after a while a bug description begins to read
> as if it is a requirement.

A lot of the differences between builds for different targets are how
the header files must be configured.  The arm-linux port needs headers
of a certain flavor, powerpc-linux and powerpc-eabi another, and so
forth.

One thing that would help, I think, now that I've built for so many
different targets in the last two weeks, is to be able to build a core
gcc that DIDN'T build libgcc1 and libgcc2.  Such a compiler could
build libraries, but wouldn't be able to build standalone executables
because it would lack all the nifty stuff that those two libs contain.

libgcc1 and libgcc2 are where a lot of the differences seem to be
creeping in, and all of them get "fixed" once you have good
target-specific headers.  You can get headers even if all you can
build are libraries.

Ergo, a truly "core" gcc wouldn't need libgcc1 and libgcc2, I don't
think, because all it would need to be able to do is build runtime
libs like glibc and newlib to get the headers; with the headers in
place, you could then build a complete gcc.

Just my $0.02.


b.g.
-- 
Bill Gatliff
bgat@open-widgets.com

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


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