Re: Cross compile error question: i686 to powerpc--linux-gnu

["William A. Gatliff" <bgat at saturn dot billgatliff dot com>]

Joe:

> a) build a bootstrap compiler, b) then build whatever library
> support with said compiler, c) and THEN manually compile and link
> whatever external stuff I need (other than barebones C support,
> which was done in step b), would there be a problem?

Depends on what you call "barebones C support".  If you're talking
just about "it understands the language, but has no support for the C
runtime environment", then as long as you have the helper functions
(which are technically part of the implementation environment, and not
the runtime environment), I think you're ok with this procedure.


> The black box I don't understand here is the aforementioned "helper
> functions" that we've been talking about.  If I want GCC to just be
> dumb and act as a compiler, can I circumvent this third step of
> recompiling the bootstrap compiler?

The SH version of gcc has helper functions with names like __udivsi3,
__ashlsi3, and __mulsi3, which implement primitive operations that
aren't natively supported by the microprocessor.  I'm not intimately
familiar with very many other gcc's, but I suspect that all ports have
at least a few helper functions.  Gcc inserts calls to these functions
in the code it generates, rather than inline the equivalent asm code.

The trouble is, I DON'T KNOW WHEN THESE FUNCTIONS ARE BUILT during the
compiler construction process.  Some of them are implemented in C
(soft-float, for example), and so they *can't* be built by the
bootstrap compiler because you don't have enough of an environment to
build them.

You don't need these functions to build libraries, obviously, but you
do need them to build applications.  The set of helper functions
needed for any particular configuration and application is highly
application and configuration specific.  So I can't make a blanket
statement like "you don't need anything other than the bootstrap
compiler" without doing a lot of non-gratis research.

> And as far as the simplicity of being able to just say
> $ gcc hello.c
>
> Isn't that almost NEVER done in a real development situation
> anyways?  Whenever I set up make and Makefile, I'm usually passing
> arguments of -c and -o to gcc.

I can't speak for anyone else, but my stuff tends to be a mixture of
-c's, -o's, and just straight gcc's, depending on what I'm up to that
day.

I think that gcc's automation of the whole process is an artifact of
its native compiler heritage.  This is a Good Thing, for me anyway.

> So, am I jumping through all of these hoops to let gcc provide
> features that I'm not going to use?  Is there some easy way to tell
> gcc when I build it that I don't want all of the collect2 nonsense
> to be built?

You're probably better off just trying to work with the setup how it
is, until you get more comfortable with what it takes to change it.
Who knows, you may even find out that you *like* gcc's current way of
doing things!  :^)


b.g.
-- 
Bill Gatliff
bgat@billgatliff.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