open9x won't compile under same environment as gruvin9x (CrossPack, on a Mac) about open9x HOT 11 CLOSED

gcc 4.7.0 is needed!
Here: avr-gcc (Fedora 4.7.0-0.fc16.1.20120302) 4.7.0 20120302 (prerelease)

Damn. Oh well, that's me out for the count then, probably. It isn't available 
(or considered stable) for the Mac, far as I know. (Wasn't last I looked, about 
two months back.) I'll have another look tomorrow. I might be able to manually 
compile it. Not holding out much hope though.

Latest version of AVR-GCC I can find for the Mac just now is gcc: 4.5.1. (I'm 
currently using v4.3.3.)

It's not good to rely on bleeding edge compilers that have not been ported to 
all systems yet.

We simply can't support all compilers. We have worked hard to test and solve 
the bugs that gcc 4.7.0 brought (i.e. the memcpy one on non aligned structs). 

Having looked some more, I don't believe this is in fact  a compiler
problem.

There's something funny going on with the (apparently auto-created) file
allsrc.cpp. The first two lines end up as ...

-n
# 1 "board_gruvin9x.cpp"

... which is obviously not going to be accepted by any compiler.

If I delete those errant lines, then open9x compiles perfectly clean -- not
a single warning.

The next time I run make (even without a make clean, it seems) then those
lines get put back into allsrc.cpp again and of course, it breaks the
compile, again.

So I guess there's just some script somewhere that isn't doing quite the
right thing -- perhaps only on my system.

Where should I start looking?

Bryan.

FOund it. Makefile line 632.

"echo -n" is not a Unix command, so we literally get a -n stuck in the new
allsrc.cpp file, from the command @echo -N > allsrc.cpp.

'touch' is a Unix command and should also have been supplied with the
compiler, as part of the standard set of utilities most Windows avr-gcc
installations come with. (Is is definitely there in my Windows installation
of WinAVR.) If this is true for you r version as well. then you could fix
this problem by changing the @echo -n allsec.cpp line to ...

touch allsrc.cpp

... which creates an empty file, named allsrc.cpp -- or sets the date/time
of an existing file to "now".

- - -

I was also really surprised to see cortex-m3 as a valid CPU target. This
suggests that the one, single installation of (is it WinAVR?) can compile
for both AVR and ARM. Is that true? If so. Wow -- I can see why you wanted
this version!

How far along is the ARM board? I haven't heard anything at all about it
since it was first announced and some mock drawings were posted.

Bryan.

No the ARM board came after open9x!!! And yes, I took a different approach than 
ersky9x: the same firmware with the same Makefile for the 3 boards. 
arm-none-eabi-gcc used. Of course not all functions available everywhere. It 
works. Features list a little bit behind v4.1 though, but far faster and a lot 
of limits removed ...
http://9xforums.com/forum/viewforum.php?f=7

I will fix the problem you found, you are right.

Bertrand.

But ... have a look:
http://unixhelp.ed.ac.uk/CGI/man-cgi?echo

Cool stuff re the ARM compiler etc.

Yes -- you are right about -n being acceptable in Unix for echo (BASH shell, at 
least.)

But the Makefile echo -n for some reason puts the -n into allsrc.cpp. I guess 
that echo is gmake internal command. So I suppose we need something like ...

@shell 'echo -n > allsrc.cpp'

???

I tried $(shell sh -c 'echo -n > allsrc.cpp'). That command also puts the -n in 
allsrc.cpp!!! I Don't understand. WTF? :/ And if that is not confusing enough, 
see what I just tested on my Windows 7 machine...

C:\Users\Bryan>echo -n >> t

C:\Users\Bryan>cat t
-n

!!!!! Am I going mad? :/ No ... the -n option is not available for Windows. It 
is not available internally for my version of gmake on the Mac either. Yet it 
works for your gmake, under Windows. CRAZY.

In then end though, simply replacing the echo line with ...

@rm -f allsrc.cpp

... is a working solution for 'all'(?) systems, since >> (append) will create 
the file if it does not already exist.  (This is not even strictly needed, if 
the last make was successful, because allsrc.cpp is then deleted.)

Yes I do like the rm solution.
Commited in the arm branch.
Will port it to the trunk today or tomorrow