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

Developer

Forums

Hey people,

So I decided to go the easier way and try to use gnude with C++. I've added the libraries libsupc++ and libc.a upon linking, but I still get the following cryptic error from the linker:

C:\gnude/arm-elf/lib/libc.a(fwrite.o)(.text+0x60): In function `fwrite':
: undefined reference to `__udivsi3'

I'm not sure if the libraries are complete or I've forgotten something.

I'm absolutely baffled and I'd appreciate some pointers on fixing this. Thanks.

I think this is defined in the libggc.a ...
/kUfa

I think this is defined in the libggc.a ...
/kUfa

Yeah, I initially thought so too, but I included it, to no avail...

Yeah, I initially thought so too, but I included it, to no avail...

Hmm the think is you not have to include *by hand* the libraries, the linker will do that for you, just tell the right library directory ( ex -Lc:/util/lib/gcc-lib/arm-elf/2.97 )
Should work nice if you have installed everything correctly..
/kUfa

Hmm the think is you not have to include *by hand* the libraries, the linker will do that for you, just tell the right library directory ( ex -Lc:/util/lib/gcc-lib/arm-elf/2.97 )
Should work nice if you have installed everything correctly..
/kUfa

I installed gnude given tyndal's recommendation, and in order to use it with C++, I followed the advice in the following thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=1638
In the makefile, I had to modify the library search paths:
LIBDIRS = -L$(GCCHOMEPATH)/lib/gcc-lib/arm-elf/3.3 -L$(GCCHOMEPATH)/arm-elf/lib
and I had to specify -lsupc++ and -c in addition to
LIBS = -lgcc -lsupc++ -lc
Normal C apps compile fine, it is the C++ app I'm having trouble with.
I really appreciate the help.

I installed gnude given tyndal's recommendation, and in order to use it with C++, I followed the advice in the following thread:
http://brewforums.qualcomm.com/showthread.php?s=&threadid=1638
In the makefile, I had to modify the library search paths:
LIBDIRS = -L$(GCCHOMEPATH)/lib/gcc-lib/arm-elf/3.3 -L$(GCCHOMEPATH)/arm-elf/lib
and I had to specify -lsupc++ and -c in addition to
LIBS = -lgcc -lsupc++ -lc
Normal C apps compile fine, it is the C++ app I'm having trouble with.
I really appreciate the help.

Woups, me laame, forgot the -lgcc stuffs..
Btw good to know you managed to get it working!
Greetz,
/kUfa

Woups, me laame, forgot the -lgcc stuffs..
Btw good to know you managed to get it working!
Greetz,
/kUfa

Nope, still not working. Same problem since the start of the thread. Just giving details of the problem. I'll let everyone know once I get something working.

Nope, still not working. Same problem since the start of the thread. Just giving details of the problem. I'll let everyone know once I get something working.

Woups sorry, was a bit tired yesterday :P
Btw can you give us the full console outputs from the compilation to see if we can help?
/kUfa

Woups sorry, was a bit tired yesterday :P
Btw can you give us the full console outputs from the compilation to see if we can help?
/kUfa

I am having the same link error as "eightyhertz" had.
Posted all theose error logs.
F:\gnude/bin/arm-elf-ld.exe -Ttext 0 --emit-relocs -entry AEEMod_Load -o weather.elf \
AEEModGen.o AEEAppGen.o GCCResolver.o preferences.o abrewapp.o AFile.o ADisplay.o AString.o ABitmap.o ABitmapStream.o AMenu.o AControl.o ADialog.o AMisc.o DlgCurrent.o DlgHourly.o DlgPrefs.o ATimer.o ASocket.o DlgWeather.o AMemory.o DlgHelp.o Dlg7Day.o DlgFavorites.o DlgSaveDone.o DlgDoppler.o DlgWeatherAlerts.o DlgVersionUpgrade.o weather.o -LF:\gnude/lib/gcc-lib/arm-elf/3.3 -LF:\gnude/arm-elf/lib -lsupc++ -lgcc -lc
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(del_op.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_personality.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_terminate.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_throw.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(pure.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(tinfo.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_alloc.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_catch.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_exception.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_globals.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/lib/gcc-lib/arm-elf/3.3/libgcc.a(_divsi3.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/lib/gcc-lib/arm-elf/3.3/libgcc.a(_dvmd_tls.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/lib/gcc-lib/arm-elf/3.3/libgcc.a(unwind-sjlj.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fwrite.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(impure.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(libcfunc.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(malloc.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(mallocr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(mlock.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(sbrkr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(syscalls.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(errno.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(findfp.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(freer.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fvwrite.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fwalk.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(memchr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(memmove.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(stdio.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(strlen.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(writer.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(wsetup.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(closer.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fflush.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(lseekr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(makebuf.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(readr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fstatr.o) does not support interworking, whereas weather.elf does
F:\gnude/arm-elf/lib/libc.a(fwrite.o)(.text+0x58): In function `fwrite':
/cygdrive/f/temp/build/build-newlib/arm-elf/newlib/libc/stdio/../../../../../newlib-1.9.0/newlib/libc/stdio/fwrite.c:103: undefined reference to `__udivsi3'
F:\gnude/arm-elf/lib/libc.a(freer.o)(.text+0x288): In function `_malloc_trim_r':
/cygdrive/f/temp/build/build-newlib/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.9.0/newlib/libc/stdlib/mallocr.c:3270: undefined reference to `__udivsi3'
make: *** [weather.elf] Error 1

I am having the same link error as "eightyhertz" had.
Posted all theose error logs.
F:\gnude/bin/arm-elf-ld.exe -Ttext 0 --emit-relocs -entry AEEMod_Load -o weather.elf \
AEEModGen.o AEEAppGen.o GCCResolver.o preferences.o abrewapp.o AFile.o ADisplay.o AString.o ABitmap.o ABitmapStream.o AMenu.o AControl.o ADialog.o AMisc.o DlgCurrent.o DlgHourly.o DlgPrefs.o ATimer.o ASocket.o DlgWeather.o AMemory.o DlgHelp.o Dlg7Day.o DlgFavorites.o DlgSaveDone.o DlgDoppler.o DlgWeatherAlerts.o DlgVersionUpgrade.o weather.o -LF:\gnude/lib/gcc-lib/arm-elf/3.3 -LF:\gnude/arm-elf/lib -lsupc++ -lgcc -lc
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(del_op.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_personality.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_terminate.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_throw.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(pure.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(tinfo.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_alloc.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_catch.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_exception.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libsupc++.a(eh_globals.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/lib/gcc-lib/arm-elf/3.3/libgcc.a(_divsi3.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/lib/gcc-lib/arm-elf/3.3/libgcc.a(_dvmd_tls.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/lib/gcc-lib/arm-elf/3.3/libgcc.a(unwind-sjlj.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fwrite.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(impure.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(libcfunc.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(malloc.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(mallocr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(mlock.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(sbrkr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(syscalls.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(errno.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(findfp.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(freer.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fvwrite.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fwalk.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(memchr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(memmove.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(stdio.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(strlen.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(writer.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(wsetup.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(closer.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fflush.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(lseekr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(makebuf.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(readr.o) does not support interworking, whereas weather.elf does
F:\gnude/bin/arm-elf-ld: Warning: F:\gnude/arm-elf/lib/libc.a(fstatr.o) does not support interworking, whereas weather.elf does
F:\gnude/arm-elf/lib/libc.a(fwrite.o)(.text+0x58): In function `fwrite':
/cygdrive/f/temp/build/build-newlib/arm-elf/newlib/libc/stdio/../../../../../newlib-1.9.0/newlib/libc/stdio/fwrite.c:103: undefined reference to `__udivsi3'
F:\gnude/arm-elf/lib/libc.a(freer.o)(.text+0x288): In function `_malloc_trim_r':
/cygdrive/f/temp/build/build-newlib/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.9.0/newlib/libc/stdlib/mallocr.c:3270: undefined reference to `__udivsi3'
make: *** [weather.elf] Error 1

I tried compiling the cppapp that comes with BREW SDK 1.1, and it didn't work either. First I had to change the "new" definitions inside the class to receive as parameter "long unsigned int" instead of "unsigned int"... It gave me a 26k mod (the one compiled using arm has around 6K, and then when I loaded it on a phone it gave me the error message "Unknown error (4)".
I tried another project that uses AEESource at some point (to use IGetLine) and it gave me the following error:
In file included from C:/gnude/1.1/inc/AEEWeb.h:29,
from web.h:9,
from web.cpp:6:
C:/gnude/1.1/inc/AEESource.h:183: error: declaration of `int
(*IGetLineVtbl::GetLine)(IGetLine*, GetLine*, int)'
C:/gnude/1.1/inc/AEESource.h:170: error: changes meaning of `GetLine' from `
typedef struct GetLine GetLine'
web.cpp: In constructor `CWeb::CWeb(signed char, short int, short int, short
int, short int)':
web.cpp:266: error: invalid conversion from `const void*' to `void*'
make: *** [web.o] Error 1
Am I missing something here?

I tried compiling the cppapp that comes with BREW SDK 1.1, and it didn't work either. First I had to change the "new" definitions inside the class to receive as parameter "long unsigned int" instead of "unsigned int"... It gave me a 26k mod (the one compiled using arm has around 6K, and then when I loaded it on a phone it gave me the error message "Unknown error (4)".
I tried another project that uses AEESource at some point (to use IGetLine) and it gave me the following error:
In file included from C:/gnude/1.1/inc/AEEWeb.h:29,
from web.h:9,
from web.cpp:6:
C:/gnude/1.1/inc/AEESource.h:183: error: declaration of `int
(*IGetLineVtbl::GetLine)(IGetLine*, GetLine*, int)'
C:/gnude/1.1/inc/AEESource.h:170: error: changes meaning of `GetLine' from `
typedef struct GetLine GetLine'
web.cpp: In constructor `CWeb::CWeb(signed char, short int, short int, short
int, short int)':
web.cpp:266: error: invalid conversion from `const void*' to `void*'
make: *** [web.o] Error 1
Am I missing something here?

I had such troubles too, but never tried any c++ code on the phone..
Be carefull, if you think that the mod is too big, something is wrong with the compilation proccess: ie the brewelf2mod DO NOT check the integrity of your elf file, as soon it is an standard obj file.. i managed to compile my code for GBA, the elf passed thru brewelf2mod without any trouble, well.. the mod was 1mb big :p
So check if you are targetting the right processor..
For the "Unknown Error 4", that means that :
- wrong processor, or
- programm entry point is NOT the AEE_ModLoad..
So a good idea is to check if you have the "-entry AEEMod_Load" (sounds like you have it) and that AEEModGen.o is the first object in the link process..
Good luck,
/kUFa

I had such troubles too, but never tried any c++ code on the phone..
Be carefull, if you think that the mod is too big, something is wrong with the compilation proccess: ie the brewelf2mod DO NOT check the integrity of your elf file, as soon it is an standard obj file.. i managed to compile my code for GBA, the elf passed thru brewelf2mod without any trouble, well.. the mod was 1mb big :p
So check if you are targetting the right processor..
For the "Unknown Error 4", that means that :
- wrong processor, or
- programm entry point is NOT the AEE_ModLoad..
So a good idea is to check if you have the "-entry AEEMod_Load" (sounds like you have it) and that AEEModGen.o is the first object in the link process..
Good luck,
/kUFa

Thanks for the tip kUfa.
I successfully compiled the cppapp from the brew examples. Just had to change the link order so AEEModGen.o was the first.
Even so, my own applications don't work. If I don't use AEESource.h, when I try to link the application, LD returns the following error:
utilfuncs.o(.text+0xbc): In function `CopyToAECHAR(char const*)':
: undefined reference to `operator new[](unsigned long)'
I implemented the operator new like this:
void * operator new( size_t size )
{
return MALLOC( size );

That worked very well with the arm compiler... Any ideas??
That happens if I don't use -lsupc++. If I use that as a parameter to LD, then a lot more errors appear...

Thanks for the tip kUfa.
I successfully compiled the cppapp from the brew examples. Just had to change the link order so AEEModGen.o was the first.
Even so, my own applications don't work. If I don't use AEESource.h, when I try to link the application, LD returns the following error:
utilfuncs.o(.text+0xbc): In function `CopyToAECHAR(char const*)':
: undefined reference to `operator new[](unsigned long)'
I implemented the operator new like this:
void * operator new( size_t size )
{
return MALLOC( size );

That worked very well with the arm compiler... Any ideas??
That happens if I don't use -lsupc++. If I use that as a parameter to LD, then a lot more errors appear...

Hello all,
Also being interested in building C++ apps with GCC, I thought I'd post I was able to get them built (and tested on live phone) by using the cygwin/gcc build environment and the tool chain contained in Gnude.
Prior to this, I had successfully built the tool chain and compiled C (and executed) apps using the downloads and instructions provided by qualcomm.
To enable c++ compile, as stated earlier in the thread:
change the following make file params:
LIBDIRS = -L$(GCCHOMEPATH)/lib/gcc-lib/arm-elf/3.3 -L$(GCCHOMEPATH)/arm-elf/lib
LIBS = -lgcc -lsupc++ -lc
Don't forget to update your INC path too:
INC = -I$(AEEINCPATH) -I$(GCCHOMEPATH)/lib/gcc-lib/arm-elf/3.3/include -I$(GCCHOMEPATH)/arm-elf/include
Other than correctly listing your source
(ie: cppapp.o: $(GCC) cppapp.cpp $(CFLAGS) -o cppapp.o ./cppapp.cpp)
I had to make no other mods to the makefile.
However, if I tried to compile at this point, I would get errors due to two problems:
1) my cygwin/gcc build had lib 3.2.3 (not 3.3 as listed above) and 2) the cygwin/gcc tool chain did not include c++ support.
Since I did not want to screw around with rebuilding that tool chain with c++ support (also have no inklng on what I would need to change), I then copied the arm-elf, bin, include, info, lib, man , and share gcc directories from the gnude install to my cygwin install.
I did get the "unsigned int" error and had to modify the CPPApp source to "long unsigned int" but was able to successfuly run the CPPApp on my T720.
kUfa, do you have a complete script of the steps taken to build your 3.3 toolchain for Gnude? I would love to be able to rebuild on my own.
One last comment: I also get the interworking warning but did not seem to effect it running on the phone.
Regards,
Rich

Hello all,
Also being interested in building C++ apps with GCC, I thought I'd post I was able to get them built (and tested on live phone) by using the cygwin/gcc build environment and the tool chain contained in Gnude.
Prior to this, I had successfully built the tool chain and compiled C (and executed) apps using the downloads and instructions provided by qualcomm.
To enable c++ compile, as stated earlier in the thread:
change the following make file params:
LIBDIRS = -L$(GCCHOMEPATH)/lib/gcc-lib/arm-elf/3.3 -L$(GCCHOMEPATH)/arm-elf/lib
LIBS = -lgcc -lsupc++ -lc
Don't forget to update your INC path too:
INC = -I$(AEEINCPATH) -I$(GCCHOMEPATH)/lib/gcc-lib/arm-elf/3.3/include -I$(GCCHOMEPATH)/arm-elf/include
Other than correctly listing your source
(ie: cppapp.o: $(GCC) cppapp.cpp $(CFLAGS) -o cppapp.o ./cppapp.cpp)
I had to make no other mods to the makefile.
However, if I tried to compile at this point, I would get errors due to two problems:
1) my cygwin/gcc build had lib 3.2.3 (not 3.3 as listed above) and 2) the cygwin/gcc tool chain did not include c++ support.
Since I did not want to screw around with rebuilding that tool chain with c++ support (also have no inklng on what I would need to change), I then copied the arm-elf, bin, include, info, lib, man , and share gcc directories from the gnude install to my cygwin install.
I did get the "unsigned int" error and had to modify the CPPApp source to "long unsigned int" but was able to successfuly run the CPPApp on my T720.
kUfa, do you have a complete script of the steps taken to build your 3.3 toolchain for Gnude? I would love to be able to rebuild on my own.
One last comment: I also get the interworking warning but did not seem to effect it running on the phone.
Regards,
Rich

Well, i think the best way is to download the latest version of gcc and recompile it for arm..
http://billgatliff.com/articles/gnu/gnu-arm7t.html/x56.html will give you some instructions how to do it, just download a newer version of gcc!
/kUfa

Well, i think the best way is to download the latest version of gcc and recompile it for arm..
http://billgatliff.com/articles/gnu/gnu-arm7t.html/x56.html will give you some instructions how to do it, just download a newer version of gcc!
/kUfa

kUfa,
I am familiar with http://billgatliff.com/articles/gnu/gnu-arm7t.html/x56.html. Those were the instructions I based my cygwin/gcc build on. However, that build does not include a c++ compiler support (though I believe it states it does). The Gnude build does include c++ (among other compilers) and was curious what the build process was for it and how it differed from each other.
Anyway, more of an academic exercise since the gnude build works great.
Thanks,
Rich

kUfa,
I am familiar with http://billgatliff.com/articles/gnu/gnu-arm7t.html/x56.html. Those were the instructions I based my cygwin/gcc build on. However, that build does not include a c++ compiler support (though I believe it states it does). The Gnude build does include c++ (among other compilers) and was curious what the build process was for it and how it differed from each other.
Anyway, more of an academic exercise since the gnude build works great.
Thanks,
Rich

Well, when you build gcc, you also build g++ so you have c++ support..
Btw i've never rebuilt anything for gnude.. sorry.. (and plain C is much faster than c++ ;)

Well, when you build gcc, you also build g++ so you have c++ support..
Btw i've never rebuilt anything for gnude.. sorry.. (and plain C is much faster than c++ ;)

Note that unless you use the "-(" and "-)" options to the GNU linker, that the ORDER of library references is order sensitive. For me, I had to use the following order:
LIBS = -lsupc++ -lc -lgcc
Note that:
LIBS = -lstdc++ -lc -lgcc
will also work (apparently auto-includes supc++).

Note that unless you use the "-(" and "-)" options to the GNU linker, that the ORDER of library references is order sensitive. For me, I had to use the following order:
LIBS = -lsupc++ -lc -lgcc
Note that:
LIBS = -lstdc++ -lc -lgcc
will also work (apparently auto-includes supc++).

Regarding using Bill Ratcliff's instructions for recentmost distributions of the tool chain.
I've had the same problem as rgaski. If you use 3.3 instead of 2.95.3 and follow all of Ratcliff's instructions, including using "--enable-languages=c,c++" for the final gcc configure, everything builds happily and reports no errors, but you don't end up with arm-elf-g++. When you try "arm-elf-gcc foo.cpp -o foo.o" you get a message like "C++ is not supported in this build".
So, with respect, I have to disagree with the optimistic claim that "when you build gcc, you also build g++". kUfa, can you confirm that your build produced an arm-elf-g++, and possibly show us the steps you took or at least let us know which versions you are using for the toolchain?
Thanks a bunch,
-Jesse

Regarding using Bill Ratcliff's instructions for recentmost distributions of the tool chain.
I've had the same problem as rgaski. If you use 3.3 instead of 2.95.3 and follow all of Ratcliff's instructions, including using "--enable-languages=c,c++" for the final gcc configure, everything builds happily and reports no errors, but you don't end up with arm-elf-g++. When you try "arm-elf-gcc foo.cpp -o foo.o" you get a message like "C++ is not supported in this build".
So, with respect, I have to disagree with the optimistic claim that "when you build gcc, you also build g++". kUfa, can you confirm that your build produced an arm-elf-g++, and possibly show us the steps you took or at least let us know which versions you are using for the toolchain?
Thanks a bunch,
-Jesse

Well, i have an arm-elf-g++.exe and arm-elf-c++.exe in my directory, after installing the whole packages.....
Interesting, i will reinstall the latest version and check, will tell ya today!

Well, i have an arm-elf-g++.exe and arm-elf-c++.exe in my directory, after installing the whole packages.....
Interesting, i will reinstall the latest version and check, will tell ya today!

Quote:Originally posted by nogara
I tried another project that uses AEESource at some point (to use IGetLine) and it gave me the following error:
In file included from C:/gnude/1.1/inc/AEEWeb.h:29,
from web.h:9,
from web.cpp:6:
C:/gnude/1.1/inc/AEESource.h:183: error: declaration of `int
(*IGetLineVtbl::GetLine)(IGetLine*, GetLine*, int)'
C:/gnude/1.1/inc/AEESource.h:170: error: changes meaning of `GetLine' from `
typedef struct GetLine GetLine'
web.cpp: In constructor `CWeb::CWeb(signed char, short int, short int, short
int, short int)':
web.cpp:266: error: invalid conversion from `const void*' to `void*'
make: *** [web.o] Error 1
Did anyone ever figure out a way around this? I've been compiling my C++ app just fine for weeks now. Just added IHtmlViewer, which includes AEESource.h.
What's the deal with this?

Quote:Originally posted by nogara
I tried another project that uses AEESource at some point (to use IGetLine) and it gave me the following error:
In file included from C:/gnude/1.1/inc/AEEWeb.h:29,
from web.h:9,
from web.cpp:6:
C:/gnude/1.1/inc/AEESource.h:183: error: declaration of `int
(*IGetLineVtbl::GetLine)(IGetLine*, GetLine*, int)'
C:/gnude/1.1/inc/AEESource.h:170: error: changes meaning of `GetLine' from `
typedef struct GetLine GetLine'
web.cpp: In constructor `CWeb::CWeb(signed char, short int, short int, short
int, short int)':
web.cpp:266: error: invalid conversion from `const void*' to `void*'
make: *** [web.o] Error 1
Did anyone ever figure out a way around this? I've been compiling my C++ app just fine for weeks now. Just added IHtmlViewer, which includes AEESource.h.
What's the deal with this?

This error is due to a Qualcomm/BREW violation of the C++ language (see "The Annotated C++ Reference Manual", pp 26-27), not to mention sloppy naming practices.
It is trivially fixed by editing line 174 of AEESource.h:
int (*GetLine) (iname *po, GetLine *pgl, int nTypeEOL);\
Insert the keyword "struct" before the second parameter type, like so:
int (*GetLine) (iname *po, struct GetLine *pgl, int nTypeEOL);\
Note that while the GNU C/C++ compilers may not generate the best (most optimized) code, they are very strict (and usually correct) in diagnosing language standard violations.
Note to moderator: Does this upgrade me from "junior developer" (I started writing software for IBM mainframes in 1962)?

This error is due to a Qualcomm/BREW violation of the C++ language (see "The Annotated C++ Reference Manual", pp 26-27), not to mention sloppy naming practices.
It is trivially fixed by editing line 174 of AEESource.h:
int (*GetLine) (iname *po, GetLine *pgl, int nTypeEOL);\
Insert the keyword "struct" before the second parameter type, like so:
int (*GetLine) (iname *po, struct GetLine *pgl, int nTypeEOL);\
Note that while the GNU C/C++ compilers may not generate the best (most optimized) code, they are very strict (and usually correct) in diagnosing language standard violations.
Note to moderator: Does this upgrade me from "junior developer" (I started writing software for IBM mainframes in 1962)?

Thanks, Dean!
I was hoping there was a switch for the GNU compiler that would allow the typedef and function to have the same name. Couldn't find a switch in the MS compiler that turned it on, either!
Does the ARM BREW Builder allow that?
So you've changed the header file, then, and haven't had a problem?
Thanks,
Tim

Thanks, Dean!
I was hoping there was a switch for the GNU compiler that would allow the typedef and function to have the same name. Couldn't find a switch in the MS compiler that turned it on, either!
Does the ARM BREW Builder allow that?
So you've changed the header file, then, and haven't had a problem?
Thanks,
Tim

According to the ARM (The Annotated C++ Reference Manual), whenever you have a type name (the typedef name in this case) and a non-type name (the function pointer name), the non-type name hides the type name (this is for compatibility with C). Thus, the GetLine typedef is effectively hidden, but the GetLine struct is not. Therefore, in order to refer to the type, you have to explicitly use the appropriate keyword ("struct" in this case).
Even when the typename is visible, you can use "struct", so while I haven't (yet) tested it on the ADS ARM compiler, it should work, as "struct" just clarifies the name usage to the compiler.
Yes, I permanently changed my copy of AEESource.h, and compile without problems.

According to the ARM (The Annotated C++ Reference Manual), whenever you have a type name (the typedef name in this case) and a non-type name (the function pointer name), the non-type name hides the type name (this is for compatibility with C). Thus, the GetLine typedef is effectively hidden, but the GetLine struct is not. Therefore, in order to refer to the type, you have to explicitly use the appropriate keyword ("struct" in this case).
Even when the typename is visible, you can use "struct", so while I haven't (yet) tested it on the ADS ARM compiler, it should work, as "struct" just clarifies the name usage to the compiler.
Yes, I permanently changed my copy of AEESource.h, and compile without problems.

you don't get upgraded by the moderators. It is a forum specification. 10 more posts and your out of there. (15 is the junior cut off) not sure about the rest, but master must be in the 100+

you don't get upgraded by the moderators. It is a forum specification. 10 more posts and your out of there. (15 is the junior cut off) not sure about the rest, but master must be in the 100+

Hmm one interesting thing.. I've just noticed that if i do not set the -lgcc at the end of the link command, it doesn t work.. maybe it's the same for those who want to compile a c++ app...
Btw sorry had no time to reinstall g++ to try it out.. but my gnude dir contains g++, if gcc works fine g++ maybe too..
Any1 knows how to remove the interworking warning, no-warn doesnt work...
/kUfa

Hmm one interesting thing.. I've just noticed that if i do not set the -lgcc at the end of the link command, it doesn t work.. maybe it's the same for those who want to compile a c++ app...
Btw sorry had no time to reinstall g++ to try it out.. but my gnude dir contains g++, if gcc works fine g++ maybe too..
Any1 knows how to remove the interworking warning, no-warn doesnt work...
/kUfa

Sorry, but find the answer of my question: --no-warn-mismatch :D
/kUfa

Sorry, but find the answer of my question: --no-warn-mismatch :D
/kUfa

Hi Everyone,
I had a successful build of the "CPPApp" example from Brew-1.1. It compiled for both Brew-1.1 and Brew-2.0. The Brew-1.1 version ran on T-720, and the Brew-2.0 version ran on another handset. Relevant files are attached.
Start by installing Gnude to "C:\Apps\Gnude", Tyndal's way (http://brewforums.qualcomm.com/showthread.php?s=&threadid=1601).
Copy the attached Copy "gppMakefile.mk" into "C:\Apps\Gnude".
My modifications are marked "yyy".
In your header file, put something like:
#ifdef ARM_DEFS
#define ARG_TYPE_FOR_NEW long unsigned int
#else
#define ARG_TYPE_FOR_NEW unsigned int
#endif
In every implementation of "new", use ARG_TYPE_FOR_NEW.
That way, your code will compile both for the emulator and with GCC.
In the "buildme.bat" file, make sure to use the right makefile and the right Brew version. The attached example includes some other small improvements, marked "yyy".
See an example errorLog.txt too.

Hi Everyone,
I had a successful build of the "CPPApp" example from Brew-1.1. It compiled for both Brew-1.1 and Brew-2.0. The Brew-1.1 version ran on T-720, and the Brew-2.0 version ran on another handset. Relevant files are attached.
Start by installing Gnude to "C:\Apps\Gnude", Tyndal's way (http://brewforums.qualcomm.com/showthread.php?s=&threadid=1601).
Copy the attached Copy "gppMakefile.mk" into "C:\Apps\Gnude".
My modifications are marked "yyy".
In your header file, put something like:
#ifdef ARM_DEFS
#define ARG_TYPE_FOR_NEW long unsigned int
#else
#define ARG_TYPE_FOR_NEW unsigned int
#endif
In every implementation of "new", use ARG_TYPE_FOR_NEW.
That way, your code will compile both for the emulator and with GCC.
In the "buildme.bat" file, make sure to use the right makefile and the right Brew version. The attached example includes some other small improvements, marked "yyy".
See an example errorLog.txt too.

Well done! Will try it today!
/kUfa

Well done! Will try it today!
/kUfa

yahelz, I can't see the attachment you mentioned... Am I missing something?

yahelz, I can't see the attachment you mentioned... Am I missing something?

Hi Everyone [hopefully with attachment],
I had a successful build of the "CPPApp" example from Brew-1.1. It compiled for both Brew-1.1 and Brew-2.0. The Brew-1.1 version ran on T-720, and the Brew-2.0 version ran on another handset. Relevant files are attached.
Start by installing Gnude to "C:\Apps\Gnude", Tyndal's way (http://brewforums.qualcomm.com/show...=&threadid=1601).
Copy the attached Copy "gppMakefile.mk" into "C:\Apps\Gnude".
My modifications are marked "yyy".
In your header file, put something like:
#ifdef ARM_DEFS
#define ARG_TYPE_FOR_NEW long unsigned int
#else
#define ARG_TYPE_FOR_NEW unsigned int
#endif
In every implementation of "new", use ARG_TYPE_FOR_NEW.
That way, your code will compile both for the emulator and with GCC.
In the "buildme.bat" file, make sure to use the right makefile and the right Brew version. The attached example includes some other small improvements, marked "yyy".
See an example errorLog.txt too.
Thanks,
Yahel.

Hi Everyone [hopefully with attachment],
I had a successful build of the "CPPApp" example from Brew-1.1. It compiled for both Brew-1.1 and Brew-2.0. The Brew-1.1 version ran on T-720, and the Brew-2.0 version ran on another handset. Relevant files are attached.
Start by installing Gnude to "C:\Apps\Gnude", Tyndal's way (http://brewforums.qualcomm.com/show...=&threadid=1601).
Copy the attached Copy "gppMakefile.mk" into "C:\Apps\Gnude".
My modifications are marked "yyy".
In your header file, put something like:
#ifdef ARM_DEFS
#define ARG_TYPE_FOR_NEW long unsigned int
#else
#define ARG_TYPE_FOR_NEW unsigned int
#endif
In every implementation of "new", use ARG_TYPE_FOR_NEW.
That way, your code will compile both for the emulator and with GCC.
In the "buildme.bat" file, make sure to use the right makefile and the right Brew version. The attached example includes some other small improvements, marked "yyy".
See an example errorLog.txt too.
Thanks,
Yahel.

Did smb try compiling and testing on mobiles the more complicated than cppapp object application?
I've been successfully collecting the simple examples and testing them at T720 and VX4400, but the point is that now I have to create a new and difficult enough game and I haven't got much time. So I think, is it worth dealing with cpp+gnude...
I'll very greatful if smb shares his experience.
Stas

Did smb try compiling and testing on mobiles the more complicated than cppapp object application?
I've been successfully collecting the simple examples and testing them at T720 and VX4400, but the point is that now I have to create a new and difficult enough game and I haven't got much time. So I think, is it worth dealing with cpp+gnude...
I'll very greatful if smb shares his experience.
Stas

Hi,
I want to put this thread back on the top.
I'm trying to compile and link my app using gnude for multiple phones with an horrible mix of C++ and C sources :) (This is what happens when you use other people's code)
I have the same question as Stas. Will it be easy to use and adapt "F:\gnude", Tyndal and Yahelz's way for multiple sources in different directories (should I flatten all sources in one sole directory?)
Any examples? (any examples using what's int this thread : http://brewforums.qualcomm.com/showthread.php?s=&threadid=2169 and in this one http://brewforums.qualcomm.com/showthread.php?s=&threadid=2033 ?)
Would it be better to use gcc with cygwin?
Should I try (more) to convince my boss to buy the RealView compiler?
Thanks to all who already have written about thsi topic.
Joël

Hi,
I want to put this thread back on the top.
I'm trying to compile and link my app using gnude for multiple phones with an horrible mix of C++ and C sources :) (This is what happens when you use other people's code)
I have the same question as Stas. Will it be easy to use and adapt "F:\gnude", Tyndal and Yahelz's way for multiple sources in different directories (should I flatten all sources in one sole directory?)
Any examples? (any examples using what's int this thread : http://brewforums.qualcomm.com/showthread.php?s=&threadid=2169 and in this one http://brewforums.qualcomm.com/showthread.php?s=&threadid=2033 ?)
Would it be better to use gcc with cygwin?
Should I try (more) to convince my boss to buy the RealView compiler?
Thanks to all who already have written about thsi topic.
Joël

I get the following when I try the above way. Any one can throw some pointers ?
e:/brewv11/inc/AEEDB.h:104: error: syntax error before `{' token
e:/brewv11/inc/AEEDB.h:108: error: parse error before `}' token
e:/brewv11/inc/AEEDB.h:108: error: ISO C++ forbids declaration of `
AEEDBFileBasicField' with no type
e:/brewv11/inc/AEEDB.h:121: error: syntax error before `{' token
e:/brewv11/inc/AEEDB.h:124: error: redefinition of `byte byFieldName'
e:/brewv11/inc/AEEDB.h:107: error: `byte byFieldName' previously declared here
e:/brewv11/inc/AEEDB.h:126: error: parse error before `}' token
e:/brewv11/inc/AEEDB.h:126: error: ISO C++ forbids declaration of `
AEEDBFileField' with no type

I get the following when I try the above way. Any one can throw some pointers ?
e:/brewv11/inc/AEEDB.h:104: error: syntax error before `{' token
e:/brewv11/inc/AEEDB.h:108: error: parse error before `}' token
e:/brewv11/inc/AEEDB.h:108: error: ISO C++ forbids declaration of `
AEEDBFileBasicField' with no type
e:/brewv11/inc/AEEDB.h:121: error: syntax error before `{' token
e:/brewv11/inc/AEEDB.h:124: error: redefinition of `byte byFieldName'
e:/brewv11/inc/AEEDB.h:107: error: `byte byFieldName' previously declared here
e:/brewv11/inc/AEEDB.h:126: error: parse error before `}' token
e:/brewv11/inc/AEEDB.h:126: error: ISO C++ forbids declaration of `
AEEDBFileField' with no type

Well, i have done games with mixed c++/c without any trouble.. btw the brew includes are only in a extern "C" ..
/kUfa

Well, i have done games with mixed c++/c without any trouble.. btw the brew includes are only in a extern "C" ..
/kUfa

I have followed all the instructions from the thread-- but in vein. I have a cpp application that finally compiles to 94kb MOD file. After the app starts, it gets reset. Heap is available adequately.
The same application runs when compiled through ARM compiler (ofcousre the size is less by 10+%).
Does the GNU do some thing that results in this ? may be stack size etc., should I check something in the mapfile ?
???

I have followed all the instructions from the thread-- but in vein. I have a cpp application that finally compiles to 94kb MOD file. After the app starts, it gets reset. Heap is available adequately.
The same application runs when compiled through ARM compiler (ofcousre the size is less by 10+%).
Does the GNU do some thing that results in this ? may be stack size etc., should I check something in the mapfile ?
???

I had the same troubles with gcc/g++, but nope with gnude

I had the same troubles with gcc/g++, but nope with gnude

In gnude, how did you compile the C++ code? arm-elf-g++ ? arm-elf-gcc ?
my app still crashes. however, RVCT ARM mod works ? Is there a good methodology for debugging this situation ?

In gnude, how did you compile the C++ code? arm-elf-g++ ? arm-elf-gcc ?
my app still crashes. however, RVCT ARM mod works ? Is there a good methodology for debugging this situation ?

I use gcc and g++
Here is an example of my .bat file (i dont use makefiles, but a laaame own-made tool to create .bat ;) )
( Name and everything are just lame example, i dont use them of course ;) )
@C:\gnude\bin\arm-elf-gcc.exe -c -I.. -fno-exceptions -fno-unwind-tables -ffunction-sections -DDYNAMIC_APP -O2 -mlittle-endian -fshort-enums -fno-builtin -mcpu=arm7tdmi -mapcs-frame -mthumb-interwork Vector\Vector.c -oLib\Vector.o
@C:\gnude\bin\arm-elf-g++.exe -c -fno-rtti -I... -fno-exceptions -fno-unwind-tables -ffunction-sections -DDYNAMIC_APP -O2 -mlittle-endian -fshort-enums -fno-builtin -mcpu=arm7tdmi -mapcs-frame -mthumb-interwork -O2 System\CPPSupport.cpp -oLib\CPPSupport.o
@C:\gnude\bin\arm-elf-ld.exe -Map test.map --cref --gc-sections --no-warn-mismatch -Ttext 0 --emit-relocs -entry AEEMod_Load -LLib EntryPoint.o A.o B.o -oLib\application.elf -lgcc
Do not forget to put the object containing AEEMod_Load in the FIRST position of the link, even if you specifiy -entry. That could be the case.. And check the mapfile aswell.
/kUFa

I use gcc and g++
Here is an example of my .bat file (i dont use makefiles, but a laaame own-made tool to create .bat ;) )
( Name and everything are just lame example, i dont use them of course ;) )
@C:\gnude\bin\arm-elf-gcc.exe -c -I.. -fno-exceptions -fno-unwind-tables -ffunction-sections -DDYNAMIC_APP -O2 -mlittle-endian -fshort-enums -fno-builtin -mcpu=arm7tdmi -mapcs-frame -mthumb-interwork Vector\Vector.c -oLib\Vector.o
@C:\gnude\bin\arm-elf-g++.exe -c -fno-rtti -I... -fno-exceptions -fno-unwind-tables -ffunction-sections -DDYNAMIC_APP -O2 -mlittle-endian -fshort-enums -fno-builtin -mcpu=arm7tdmi -mapcs-frame -mthumb-interwork -O2 System\CPPSupport.cpp -oLib\CPPSupport.o
@C:\gnude\bin\arm-elf-ld.exe -Map test.map --cref --gc-sections --no-warn-mismatch -Ttext 0 --emit-relocs -entry AEEMod_Load -LLib EntryPoint.o A.o B.o -oLib\application.elf -lgcc
Do not forget to put the object containing AEEMod_Load in the FIRST position of the link, even if you specifiy -entry. That could be the case.. And check the mapfile aswell.
/kUFa

Actually when I compile with RVCT, the app runs fine as I said earlier.
Now, if I create the mod file using arm-elf-gcc-- IT WORKS.. but after a while the phone gets reset. If it is an entry point problem, first of all the application should not start.
In theory or practice, if something is different between GNUDE and RVCT, the app should not run 50% & then fail. (Ofcourse this sounds silly-- but I am in a mess)

Actually when I compile with RVCT, the app runs fine as I said earlier.
Now, if I create the mod file using arm-elf-gcc-- IT WORKS.. but after a while the phone gets reset. If it is an entry point problem, first of all the application should not start.
In theory or practice, if something is different between GNUDE and RVCT, the app should not run 50% & then fail. (Ofcourse this sounds silly-- but I am in a mess)

Sorry i misunderstand you when you said "start then crashes".
Yop that's weird..
Just double check the compiler is not creating static variables, ie ensure you have something like
.data 0x00014788 0x0
0x00014788 __data_start = .
*(.data .data.* .gnu.linkonce.d.*)
.data1
*(.data1)
in your map file (0x0 bytes of static data)
I had something similar
/kUfa

Sorry i misunderstand you when you said "start then crashes".
Yop that's weird..
Just double check the compiler is not creating static variables, ie ensure you have something like
.data 0x00014788 0x0
0x00014788 __data_start = .
*(.data .data.* .gnu.linkonce.d.*)
.data1
*(.data1)
in your map file (0x0 bytes of static data)
I had something similar
/kUfa

I checked that the data segment is empty. If it were not, even RVCT should throw errors I think.

I checked that the data segment is empty. If it were not, even RVCT should throw errors I think.

Not if gnude create some weird code internaly. Eg it created me static data for a typedef enum which was in a .cpp, but worked fine once in a .c ...
/kUfa

Not if gnude create some weird code internaly. Eg it created me static data for a typedef enum which was in a .cpp, but worked fine once in a .c ...
/kUfa

OK, I started debugging the situation and tried with ###5 Debug MALLOC. I got a #*g**=-5 in the logger and then the phone got reset. Supposing that the MALLOC failed, I wonder why this does not happen with the RVCT Mod. I am using Audiovox8600.

OK, I started debugging the situation and tried with ###5 Debug MALLOC. I got a #*g**=-5 in the logger and then the phone got reset. Supposing that the MALLOC failed, I wonder why this does not happen with the RVCT Mod. I am using Audiovox8600.

What is the RCVT Mod?
Confused.
OT:
I want to make the output from gnude go from the errorlog.txt file to the output window in VC++.
Anyone know?
Peace.

What is the RCVT Mod?
Confused.
OT:
I want to make the output from gnude go from the errorlog.txt file to the output window in VC++.
Anyone know?
Peace.

I was indicating RVCT (real view compilation tools for brew).

I was indicating RVCT (real view compilation tools for brew).

kUfa,
Can you talk a little more about this static data?
I checked my .map file & found the same pattern:
.data 0x00002c84 0x0
0x00002c84 __data_start = .
*(.data .data.* .gnu.linkonce.d.*)
What does this mean? Any pointers?
Thank you,
Nick
Quote:Originally posted by kUfa
Sorry i misunderstand you when you said "start then crashes".
Yop that's weird..
Just double check the compiler is not creating static variables, ie ensure you have something like
.data 0x00014788 0x0
0x00014788 __data_start = .
*(.data .data.* .gnu.linkonce.d.*)
.data1
*(.data1)
in your map file (0x0 bytes of static data)
I had something similar
/kUfa

kUfa,
Can you talk a little more about this static data?
I checked my .map file & found the same pattern:
.data 0x00002c84 0x0
0x00002c84 __data_start = .
*(.data .data.* .gnu.linkonce.d.*)
What does this mean? Any pointers?
Thank you,
Nick
Quote:Originally posted by kUfa
Sorry i misunderstand you when you said "start then crashes".
Yop that's weird..
Just double check the compiler is not creating static variables, ie ensure you have something like
.data 0x00014788 0x0
0x00014788 __data_start = .
*(.data .data.* .gnu.linkonce.d.*)
.data1
*(.data1)
in your map file (0x0 bytes of static data)
I had something similar
/kUfa

On your line .data 0x00002c84 0x0 the latest number is the total size of static data, here 0 which is how it should be.
Just dont use static data, ie dont use the static keyword unless it's for a constant (static const int is ok), and dont use any field outside methods.
/kUfa

On your line .data 0x00002c84 0x0 the latest number is the total size of static data, here 0 which is how it should be.
Just dont use static data, ie dont use the static keyword unless it's for a constant (static const int is ok), and dont use any field outside methods.
/kUfa

Thanks!

Thanks!