avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Anyone ever compiled avr-gcc on ! IA32 platforms?


From: J Wunsch
Subject: [avr-gcc-list] Anyone ever compiled avr-gcc on ! IA32 platforms?
Date: Fri, 23 Mar 2001 11:08:50 +0100

Hi all,

i recently noticed that my FreeBSD port of avr-gcc (*) failed to
compile on the Alpha architecture.

(*) A FreeBSD port is basically a packaging framework around software
that can be fetched from the Internet.  It always adds dependencies
and description files, and could add patches if required, but despite
of the name, even software that compiles out of the box directly from
the Internet version needs a `port' in order to have a pre-compiled
binary package on the distribution CD-ROMs.

[Note that the following is all about gcc 2.95.x, since basically a
port builds upon Internet-available distribution files, i. e. i can't
afford to do something like a CVS checkout within a port.  So should
the following problem already be fixed in the current development
version, i'll be glad to hear it as well.]

I was somewhat surprised by the fact, since i couldn't think of a way
why a cross-development software that works on host architecture A
would not run on host architecture B as well.  I investigated a
little, and found that gcc's build framework by default generated a
CFLAGS macro of "-O -pipe -mcpu=ev4" on the Alpha host platform.
While this might be OK as far as it is used to generate code that is
intented to run on the host platform, like the compiler tools itself,
it gets completely bogus when it comes to the stage where the new-born
gcc tries to compile its libgcc.  It seems to me that gcc's build
framework is, well, broken in this respect.  First, IMHO it should
always use CFLAGS_FOR_TARGET in that case, but while this macro
appears to be generated at the top-level Makefile, it's not inherited
across the build hierarchy, so the subdirectory Makefiles only have
CFLAGS to use.  Second, i couldn't find a way to convince the
configure script to set CFLAGS_FOR_TARGET different from the default
CFLAGS.  (The original value of CFLAGS is somehow generated by
config.guess, that's where the -mcpu=ev4 seems to originate, although
i didn't find out how this is actually being created.)

By now, i cheated by forcing the configure script into always using
"-O -pipe" for CFLAGS (-O2 is broken on the Alpha, so i can't use
that), but i'd like to know whether there's a better way.  Maybe i
simply overlooked something.

-- 
Joerg Wunsch             NIC hdl: JW11-RIPE             On the air: DL8DTL
See http://www.interface-business.de/~j/ for more information.

Some addresses in the headers might be wrong (sorry - I'm not the admin here).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]