[En-Nut-Discussion] still can't compile xsvfexec

[Harald Kipp]

Tom,

At 10:47 22.02.2006 -0500, you wrote:

>Directory).  I then replaced the original XVSF file in the cpld
>directory (enut30d.xvsf) with enut202.xsvf (after renaming it) and
>tried to build the package according to the instructions:

It must not be renamed. The -DETHERNUT2 compiler switch tells the
Executor to use enut202.xsvf (see host.h).

But the Makefile is for Ethernut 3 only. Thus you need to change
the entry in this file.


>I understand that the compiler thinks that the urom.c contains a data
>structure that is too large.  What I don't understand is why I can't
>compile the unmodified code and unchanged XSVF file straight out of the
>zip file I downloaded.  Surely this should work, at least for the
>xsvfexec101.zip and the Ethernut2.1b board??

Now I tried myself...and indeed...same result with xsvfexec 1.1.2.

I switched back from gcc 3.4.5 to gcc 3.3.1 (WinAVR-20030913),
same result.

Then I unpacked xsvfexec101.zip from
http://www.ethernut.de/arc/

The Makefile it contains is old and doesn't work with a Configurator
Build Tree. I removed the top_srcdir definition and replaced

include $(top_srcdir)/app/Makedefs
include $(top_srcdir)/app/Makerules

with

include ../Makedefs
include ../Makerules

Now I could at least create the UROM file system with

make urom.o

One thing remains, the same ol' story with libraries.
Appending

     -lnutarch -lnutdev

to the LIBS entry in the Makefile solved this final problem
and xsvfexec was build finally.

Phew! Do not ask, what's happening here. There is a limit
in GCC. All program space data must fit in the lower 64kB.
May be somewhere in that area is going wrong with
xsvfexec 1.1.2.

Thanks for _your_ patience,

Harald