Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

I am trying to build the whiteboard example from the provided mak file.

My environment is cygwin on winxp and built I the entire arm-elf toolchain via the instructions at http://billgatliff.com/articles/gnu/gnu-arm7t.html/x56.html (also used same tool package versions just for sanity). I have tested the tools and appear to be working/compiling properly using example case provided by instructions.

However, when I compile whiteboard.mak, I get the following error and wondered anyone had come across the same the issue:

$ make -f whiteboard-gcc.mak all

c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm

i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I

../../inc -Ic:/cygwin/home/rgaski/install\lib\gcc-lib\arm-elf\2.95\include -Ic:/

cygwin/home/rgaski/install\arm-elf\include -O2 -o WhiteBoard.o ./WhiteBoard.c

In file included from WhiteBoard.h:49,

from ./WhiteBoard.c:45:

../../inc/AEEFile.h:131: parse error before `__packed'

./WhiteBoard.c: In function `WB_DisplaySampleShape':

./WhiteBoard.c:2046: Internal compiler error in `purge_addressof_1', at function

.c:3183

Please submit a full bug report.

See http://www.gnu.org/software/gcc/bugs.html> for instructions.

make: *** [WhiteBoard.o] Error 1

Any thoughts?

Quote:../../inc/AEEFile.h:131: parse error before `__packed'
I believe you have included some of the ARM ADS libraries or have not properly changed the environment variables. __packed should only be defined in ARM. GNU should not know about this. You may also be compiling against the 1.1 SDK? Can you check that your BREWDIR is set correctly?
I am working to build the sources myself and will let you know if I run into similar issues.

Quote:../../inc/AEEFile.h:131: parse error before `__packed'
I believe you have included some of the ARM ADS libraries or have not properly changed the environment variables. __packed should only be defined in ARM. GNU should not know about this. You may also be compiling against the 1.1 SDK? Can you check that your BREWDIR is set correctly?
I am working to build the sources myself and will let you know if I run into similar issues.

Thanks for the prompt reply.
Yes, I am building with 2.0.1 SDK. (BREWDIR is set to c:\progra~1\brewsd~1.1). However, I'm not sure which other environment variables should be changed other than what's in the mak file. What vars are you referring to?
Please post your results when you finish building the tools. I noticed a discrepancy in the mak file, which had LIBDIRS and INC point to a 2.97 version of gcc (INC = -I$(AEEINCPATH) -I$(GCCHOMEPATH)\lib\gcc-lib\arm-elf\2.97\include -I$(GCCHOMEPATH)\arm-elf\include) rather than 2.95.3.
As an aside, I did try 2.97 gcc and that also returned the same error.
Rich

Thanks for the prompt reply.
Yes, I am building with 2.0.1 SDK. (BREWDIR is set to c:\progra~1\brewsd~1.1). However, I'm not sure which other environment variables should be changed other than what's in the mak file. What vars are you referring to?
Please post your results when you finish building the tools. I noticed a discrepancy in the mak file, which had LIBDIRS and INC point to a 2.97 version of gcc (INC = -I$(AEEINCPATH) -I$(GCCHOMEPATH)\lib\gcc-lib\arm-elf\2.97\include -I$(GCCHOMEPATH)\arm-elf\include) rather than 2.95.3.
As an aside, I did try 2.97 gcc and that also returned the same error.
Rich

I was able to compile and run the example. I used the 3.2.3 source, but you should be fine with the 2.97 and later (maybe you did not clean your 2.95 fully). Make sure your PATH picks up from your build environment first. I had some issues with picking up other gcc installed libs.
Sorry I can't be of more help ...I believe it is a configuration issue. I am running XP. Let me know if you have other questions.

I was able to compile and run the example. I used the 3.2.3 source, but you should be fine with the 2.97 and later (maybe you did not clean your 2.95 fully). Make sure your PATH picks up from your build environment first. I had some issues with picking up other gcc installed libs.
Sorry I can't be of more help ...I believe it is a configuration issue. I am running XP. Let me know if you have other questions.

I've rebuilt from scratch and still getting the same error. I'm pretty sure I'm over looking something very basic.
Can you reply with more specific information on how your variables are set and also a copy of your build output. That may help me resolve my problem.
Thx again,
Rich

I've rebuilt from scratch and still getting the same error. I'm pretty sure I'm over looking something very basic.
Can you reply with more specific information on how your variables are set and also a copy of your build output. That may help me resolve my problem.
Thx again,
Rich

Maybe you should try building the 3.2.3 source. I think you can find the pre-compiled binaries on the net as well.
I cleaned the build logs out. Sorry.
Are you building to a new location as recommended in the article.
//source tree
C:\GNU\gcc-3.2.3
//build dir
C:\GNU\build-gcc
//final location
C:\GNU\install
Try removing any PATH information that points to old gnu installs, or arm directories.

Maybe you should try building the 3.2.3 source. I think you can find the pre-compiled binaries on the net as well.
I cleaned the build logs out. Sorry.
Are you building to a new location as recommended in the article.
//source tree
C:\GNU\gcc-3.2.3
//build dir
C:\GNU\build-gcc
//final location
C:\GNU\install
Try removing any PATH information that points to old gnu installs, or arm directories.

Starting with cygwin default setup plus all development tools, I built exactly to the instructions. I've tried simplifying and rearranging the PATH. I've removed any files that were not essential for the cross compile.
I'm not sure what else I can try.
I guess I'll have to wait until gcc is officially supported. Has anyone else gotten this to work following those instructions?
Regards,
Rich

Starting with cygwin default setup plus all development tools, I built exactly to the instructions. I've tried simplifying and rearranging the PATH. I've removed any files that were not essential for the cross compile.
I'm not sure what else I can try.
I guess I'll have to wait until gcc is officially supported. Has anyone else gotten this to work following those instructions?
Regards,
Rich

I found your error.
You are compiling with 1.1 SDK headers.
__packed will be generated for 1.1 compiles. In my efforts to get the GCC to work in 1.1 I came across the same error. When I get the 1.1 SDK to compile with the GCC will post the info.

I found your error.
You are compiling with 1.1 SDK headers.
__packed will be generated for 1.1 compiles. In my efforts to get the GCC to work in 1.1 I came across the same error. When I get the 1.1 SDK to compile with the GCC will post the info.

Interesting ... I only have SDK 2.0.1 installed and am using those headers, not 1.1. Let me know what you find out.
Rich

Interesting ... I only have SDK 2.0.1 installed and am using those headers, not 1.1. Let me know what you find out.
Rich

I took a look at the 2.0.1 header files, and it looks like AEEFile.h uses PACKED, which is defined in AEEComdef.h:
#if defined(__arm)
#define PACKED __packed
#else
#define PACKED
#endif
This code is assuming that __arm will not be defined when compiling with GCC. I don't know why __arm would be defined, but you might want to try editing AEEComdef.h to make sure that PACKED is defined correctly for GCC. (Just don't use the edited header with armcc.)

I took a look at the 2.0.1 header files, and it looks like AEEFile.h uses PACKED, which is defined in AEEComdef.h:
#if defined(__arm)
#define PACKED __packed
#else
#define PACKED
#endif
This code is assuming that __arm will not be defined when compiling with GCC. I don't know why __arm would be defined, but you might want to try editing AEEComdef.h to make sure that PACKED is defined correctly for GCC. (Just don't use the edited header with armcc.)

I've tried this too. I've tried removing PACKED from AEEFile.h and modifying the defination in AEEComdef.h.
The best I get is the ommision of that error, however still resulting in:
$ make -f whiteboard-gcc.mak all
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o AEEModGen.o ../../src/AEEM
odGen.c
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o AEEAppGen.o ../../src/AEEA
ppGen.c
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o WB_RGBCtl.o ./WB_RGBCtl.c
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o GCCResolver.o ../../src/mi
sc/GCCResolver.c
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o WhiteBoard.o ./WhiteBoard.
c
./WhiteBoard.c: In function `WB_DisplaySampleShape':
./WhiteBoard.c:2046: Internal compiler error in `purge_addressof_1', at function
.c:3183
Please submit a full bug report.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
make: *** [WhiteBoard.o] Error 1

I've tried this too. I've tried removing PACKED from AEEFile.h and modifying the defination in AEEComdef.h.
The best I get is the ommision of that error, however still resulting in:
$ make -f whiteboard-gcc.mak all
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o AEEModGen.o ../../src/AEEM
odGen.c
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o AEEAppGen.o ../../src/AEEA
ppGen.c
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o WB_RGBCtl.o ./WB_RGBCtl.c
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o GCCResolver.o ../../src/mi
sc/GCCResolver.c
c:/cygwin/home/rgaski/install/bin/arm-elf-gcc.exe -c -DDYNAMIC_APP -mcpu=arm7tdm
i -mapcs-frame -mthumb-interwork -mlittle-endian -fshort-enums -fno-builtin -I
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o WhiteBoard.o ./WhiteBoard.
c
./WhiteBoard.c: In function `WB_DisplaySampleShape':
./WhiteBoard.c:2046: Internal compiler error in `purge_addressof_1', at function
.c:3183
Please submit a full bug report.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
make: *** [WhiteBoard.o] Error 1

I found this link after some googling:
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00222.html
Looks like the same error. Are you seeing this particular error on both 2.95 and 2.97?

I found this link after some googling:
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00222.html
Looks like the same error. Are you seeing this particular error on both 2.95 and 2.97?

yes, I'll give a look ...
Rich

yes, I'll give a look ...
Rich

Please don't edit the 2.0 headers, it is not needed.
Have you tried compiling the 3.2.3 source yet?

Please don't edit the 2.0 headers, it is not needed.
Have you tried compiling the 3.2.3 source yet?

I get an error while compiling for 3.2.3.
I get this far:
cd
mkdir build-binutils
mkdir build-gcc
mkdir build-newlib
mkdir build-gdb
mkdir install
export TARGET=arm-elf
export PREFIX=`pwd`/install
export PATH=$PATH:$PREFIX/bin
tar xzvf binutils-2.13.2.1.tar.gz
tar xzvf gcc-3.2.3.tar.gz
tar xzvf newlib-1.11.0.tar.gz
cd build-binutils
../binutils-2.13.2.1/configure --target=$TARGET --prefix=$PREFIX
make all install 2>&1 | tee make.log
cd ..
cd build-gcc
../gcc-3.2.3/configure --target=$TARGET -prefix=$PREFIX --with-newlib --without-headers --with-gnu-as --with-gnu-ld --disable-shared --enable-languages=c
make all-gcc install-gcc 2>&1 | tee make.log
which results in:
gcc -DIN_GCC -DHAVE_CONFIG_H -DIN_GCC -DCROSS_COMPILE -g -O2 -W -Wall -Wwrite-st
rings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long
-long -DHAVE_CONFIG_H -DGENERATOR_FILE -W -Wall -Wwrite-strings -Wstrict-protot
ypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -I. -I.. -I../.
./../gcc-3.2.3/gcc/fixinc -I../../../gcc-3.2.3/gcc/fixinc/.. -I../../../gcc-3.2.
3/gcc/fixinc/../config -I../../../gcc-3.2.3/gcc/fixinc/../../include -o fixincl
.exe fixincl.o fixtests.o fixfixes.o server.o procopen.o gnu-regex.o fixlib.o ..
/../libiberty/libiberty.a
gnu-regex.o(.text+0x6556): In function `regerror':
/home/rgaski/build-gcc/gcc/fixinc/../../../gcc-3.2.3/gcc/fixinc/gnu-regex.c:5723
: undefined reference to `___mempcpy'
collect2: ld returned 1 exit status
make[2]: *** [full-stamp] Error 1
make[2]: Leaving directory `/home/rgaski/build-gcc/gcc/fixinc'
make[1]: *** [fixinc.sh] Error 2
make[1]: Leaving directory `/home/rgaski/build-gcc/gcc'
make: *** [all-gcc] Error 2
What versions & patches are you using to build the 3.2.3 tools?
Rich

I get an error while compiling for 3.2.3.
I get this far:
cd
mkdir build-binutils
mkdir build-gcc
mkdir build-newlib
mkdir build-gdb
mkdir install
export TARGET=arm-elf
export PREFIX=`pwd`/install
export PATH=$PATH:$PREFIX/bin
tar xzvf binutils-2.13.2.1.tar.gz
tar xzvf gcc-3.2.3.tar.gz
tar xzvf newlib-1.11.0.tar.gz
cd build-binutils
../binutils-2.13.2.1/configure --target=$TARGET --prefix=$PREFIX
make all install 2>&1 | tee make.log
cd ..
cd build-gcc
../gcc-3.2.3/configure --target=$TARGET -prefix=$PREFIX --with-newlib --without-headers --with-gnu-as --with-gnu-ld --disable-shared --enable-languages=c
make all-gcc install-gcc 2>&1 | tee make.log
which results in:
gcc -DIN_GCC -DHAVE_CONFIG_H -DIN_GCC -DCROSS_COMPILE -g -O2 -W -Wall -Wwrite-st
rings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long
-long -DHAVE_CONFIG_H -DGENERATOR_FILE -W -Wall -Wwrite-strings -Wstrict-protot
ypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -I. -I.. -I../.
./../gcc-3.2.3/gcc/fixinc -I../../../gcc-3.2.3/gcc/fixinc/.. -I../../../gcc-3.2.
3/gcc/fixinc/../config -I../../../gcc-3.2.3/gcc/fixinc/../../include -o fixincl
.exe fixincl.o fixtests.o fixfixes.o server.o procopen.o gnu-regex.o fixlib.o ..
/../libiberty/libiberty.a
gnu-regex.o(.text+0x6556): In function `regerror':
/home/rgaski/build-gcc/gcc/fixinc/../../../gcc-3.2.3/gcc/fixinc/gnu-regex.c:5723
: undefined reference to `___mempcpy'
collect2: ld returned 1 exit status
make[2]: *** [full-stamp] Error 1
make[2]: Leaving directory `/home/rgaski/build-gcc/gcc/fixinc'
make[1]: *** [fixinc.sh] Error 2
make[1]: Leaving directory `/home/rgaski/build-gcc/gcc'
make: *** [all-gcc] Error 2
What versions & patches are you using to build the 3.2.3 tools?
Rich

I got this error as well. Make sure your path does not pick up cygwin installation lib's
export PATH=$PATH:$PREFIX/bin
should be
export PATH=$PREFIX/bin:$PATH
clean your build before continuing.

I got this error as well. Make sure your path does not pick up cygwin installation lib's
export PATH=$PATH:$PREFIX/bin
should be
export PATH=$PREFIX/bin:$PATH
clean your build before continuing.

It made no difference whether building for 2.95.3 or 3.2.2.
Rich

It made no difference whether building for 2.95.3 or 3.2.2.
Rich

Quote:
/home/rgaski/build-gcc/gcc/fixinc/../../../gcc-3.2.3/gcc/fixinc/gnu-regex.c:5723
: undefined reference to `___mempcpy'
look in the file and find:
#if defined HAVE_MEMPCPY || defined _LIBC
*((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
#else
memcpy (errbuf, msg, errbuf_size - 1);
errbuf[errbuf_size - 1] = 0;
#endif
edit this to force memcpy rather than __mempcpy:
//#if defined HAVE_MEMPCPY || defined _LIBC
// *((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
//#else
memcpy (errbuf, msg, errbuf_size - 1);
errbuf[errbuf_size - 1] = 0;
//#endif
save and recompile. That worked for me when I tested building on a clean Win2K machine. I got an error with a thumb library when building the final gcc, but it built the arm-elf-gcc already and I was able to compile the WhiteBoard example and run it on a device. I if your feeling adventurous you can dig deeper, HAVE_MEMPCPY is defined in localealias.c
note: I did not get any of these issues compiling the 3.2.3 source from my XP machine. But maybe the tar ball I got was different or it is some other variable.

Quote:
/home/rgaski/build-gcc/gcc/fixinc/../../../gcc-3.2.3/gcc/fixinc/gnu-regex.c:5723
: undefined reference to `___mempcpy'
look in the file and find:
#if defined HAVE_MEMPCPY || defined _LIBC
*((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
#else
memcpy (errbuf, msg, errbuf_size - 1);
errbuf[errbuf_size - 1] = 0;
#endif
edit this to force memcpy rather than __mempcpy:
//#if defined HAVE_MEMPCPY || defined _LIBC
// *((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
//#else
memcpy (errbuf, msg, errbuf_size - 1);
errbuf[errbuf_size - 1] = 0;
//#endif
save and recompile. That worked for me when I tested building on a clean Win2K machine. I got an error with a thumb library when building the final gcc, but it built the arm-elf-gcc already and I was able to compile the WhiteBoard example and run it on a device. I if your feeling adventurous you can dig deeper, HAVE_MEMPCPY is defined in localealias.c
note: I did not get any of these issues compiling the 3.2.3 source from my XP machine. But maybe the tar ball I got was different or it is some other variable.

Hooray, this did the trick, although I also got the same thumb library error.
One comment, the .mak file did not find arm-elf-objdump.exe properly when running the elf2modtool. I made this slight tweak in my .mak file to correct:
1) added OBJDUMP to my path list:
GCC = $(GCCBINPATH)/arm-elf-gcc.exe
LD = $(GCCBINPATH)/arm-elf-ld.exe
OBJDUMP = $(GCCBINPATH)/arm-elf-objdump.exe
ELF2MODTOOL = $(ELF2MODTOOLPATH)/BREWelf2mod.exe
2) modified target as such:
$(TARGET).$(MODULE) : $(TARGET).$(EXETYPE)
$(ELF2MODTOOL) $(TARGET).$(EXETYPE) $(TARGET).$(MODULE) $(OBJDUMP)
Now I'm almost there! I finally got a mod built. I got a test sig file from the web and loaded it to my T720 using the New > Module option in AppLoader and alas it does not recognize it (or at least show up in my list of apps). Even after reset the app is not recognized although it does show up in AppLoader.
Can I email the mod file to verify that it does indeed work (cannot attach .mod files in this forum) and was compiled correctly? It is 21676 bytes.
Once I've confirmed that the compile did work, I'll repost a full description of the steps I took and any problems I encountered to help other avoid any of these pitfalls.
Rich

Hooray, this did the trick, although I also got the same thumb library error.
One comment, the .mak file did not find arm-elf-objdump.exe properly when running the elf2modtool. I made this slight tweak in my .mak file to correct:
1) added OBJDUMP to my path list:
GCC = $(GCCBINPATH)/arm-elf-gcc.exe
LD = $(GCCBINPATH)/arm-elf-ld.exe
OBJDUMP = $(GCCBINPATH)/arm-elf-objdump.exe
ELF2MODTOOL = $(ELF2MODTOOLPATH)/BREWelf2mod.exe
2) modified target as such:
$(TARGET).$(MODULE) : $(TARGET).$(EXETYPE)
$(ELF2MODTOOL) $(TARGET).$(EXETYPE) $(TARGET).$(MODULE) $(OBJDUMP)
Now I'm almost there! I finally got a mod built. I got a test sig file from the web and loaded it to my T720 using the New > Module option in AppLoader and alas it does not recognize it (or at least show up in my list of apps). Even after reset the app is not recognized although it does show up in AppLoader.
Can I email the mod file to verify that it does indeed work (cannot attach .mod files in this forum) and was compiled correctly? It is 21676 bytes.
Once I've confirmed that the compile did work, I'll repost a full description of the steps I took and any problems I encountered to help other avoid any of these pitfalls.
Rich

Hehe, I'm building on SDK 2.0.1 so it makes sense that it doesn't run on T720 (1.1). Let me try that before I keep asking for help.
Rich

Hehe, I'm building on SDK 2.0.1 so it makes sense that it doesn't run on T720 (1.1). Let me try that before I keep asking for help.
Rich

Ok, I built the helloworld app from the 1.1 SDK. It seemed to compile properly. Ended up with a 2368 byte mod file.
Got a sig file from the web and the example .mif file when using AppLoader to load the module. I have the same issue as before. The app does not show up on the phone.
Yes, I know the GNU Tools is supposed to work for SDK 2.0 or better but I thought I'd give it a try. It looks like it compiled ok.
Again, I'd like to isolate this as a problem with the compiler or a problem with my loading to the phone.
I'd like to have someone verify that the mod files I have work on a phone so I can move on to figuring out why my phone doesn't like the apps or looking deeper into the compiler issues.
Rich

Ok, I built the helloworld app from the 1.1 SDK. It seemed to compile properly. Ended up with a 2368 byte mod file.
Got a sig file from the web and the example .mif file when using AppLoader to load the module. I have the same issue as before. The app does not show up on the phone.
Yes, I know the GNU Tools is supposed to work for SDK 2.0 or better but I thought I'd give it a try. It looks like it compiled ok.
Again, I'd like to isolate this as a problem with the compiler or a problem with my loading to the phone.
I'd like to have someone verify that the mod files I have work on a phone so I can move on to figuring out why my phone doesn't like the apps or looking deeper into the compiler issues.
Rich

I found this error too. I guess that looks mystical but the problem was fixed when I inserted a few empty lines before line 1973 (
rLine.sx = rViewportRect.dx / 3;)
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o WhiteBoard.o ./WhiteBoard.
c
./WhiteBoard.c: In function `WB_DisplaySampleShape':
./WhiteBoard.c:2046: Internal compiler error in `purge_addressof_1', at function
.c:3183
Please submit a full bug report.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
make: *** [WhiteBoard.o] Error 1 [/B]

I found this error too. I guess that looks mystical but the problem was fixed when I inserted a few empty lines before line 1973 (
rLine.sx = rViewportRect.dx / 3;)
../../inc -Ic:/cygwin/home/rgaski/install/lib/gcc-lib/arm-elf/2.95.3/include -Ic
:/cygwin/home/rgaski/install/arm-elf/include -O2 -o WhiteBoard.o ./WhiteBoard.
c
./WhiteBoard.c: In function `WB_DisplaySampleShape':
./WhiteBoard.c:2046: Internal compiler error in `purge_addressof_1', at function
.c:3183
Please submit a full bug report.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
make: *** [WhiteBoard.o] Error 1 [/B]

At least I wasn't alone!
I did verify that the 2.0 mod I built worked although I haven't been able to test the 1.1 mod since I don't have a test enabled phone.
Thx,
Rich

At least I wasn't alone!
I did verify that the 2.0 mod I built worked although I haven't been able to test the 1.1 mod since I don't have a test enabled phone.
Thx,
Rich