#16526 - shaktool - Wed Feb 18, 2004 10:18 pm
I'm currently using http://gnufoo.org/gbasdk/gbasdk.html (minus the whole SGADE thing) to compile my games written in C, but I've decided I want to use C++ for my next game, which will have a variable number of many different kinds of entities that all need to interact with each other and stuff like that...
However, the gcc that comes with that GBASDK will not compile C++. Does anybody know of a cross-compiler for Mac (or, you know, Unix) that will compile C++ for GBA? Or if not, does anybody have any idea how I could compile one, based on DevKit Advance or something?
Do not assume that I know what I'm doing :)
#16527 - poslundc - Wed Feb 18, 2004 11:27 pm
Use g++ instead of gcc to compile C++ code.
Dan.
#16528 - shaktool - Wed Feb 18, 2004 11:50 pm
Yeah, that's the thing. I don't have g++. I've got:
addr2line
ar
as
c++filt
cpp
gasp
gcc
gccbug
gcov
ld
nm
etc...
All that is in /usr/local/gbasdk/arm-agb-elf/bin/
Is there a version of g++ for Unix out there that I'm missing?
#16533 - tepples - Thu Feb 19, 2004 12:27 am
Because of the size of the C++ compiler and its standard library, some GCC distributions put C++ support in a separate library. Go back to the site where you downloaded the cross-GCC distribution and see if it offers a C++ package. Or find another cross-GCC distribution. Or roll your own based on the GCC source code from GNU.org.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#16534 - poslundc - Thu Feb 19, 2004 12:28 am
Hm, yeah, this isn't the only area I've noticed where the GBASDK seems to be incomplete. :P
I think you may be in luck; there's another OS X distribution of gcc available from velvetfr (http://velvetfr.ath.cx/tools/gba.html at the bottom of the page), and it's even a newer version.
If that doesn't work for you, if you want g++ I suppose you could always try recompiling gcc from the sources, but that's not exactly a fun way to spend an afternoon.
Me, I'm still using GBASDK. Talk about lazy!
Good luck,
Dan.
#16546 - shaktool - Thu Feb 19, 2004 6:09 am
Well, yeah, it looked good, until I tried to run it... Even compiling my old C code (which worked fine before) in the new gcc didn't work, let alone compiling it as C++ with g++. I got a few hundred errors like this.
foo.c:2:Unknown pseudo-op: .global
foo.c:2:Rest of line ignored. 1st junk character valued 66 (B).
foo.c:3:Expected comma after segment-name
foo.c:3:Rest of line ignored. 1st junk character valued 32 ( ).
foo.c:4:Unknown pseudo-op: .type
foo.c:4:Rest of line ignored. 1st junk character valued 66 (B).
foo.c:5:Unknown pseudo-op: .size
At least it tried to compile the C++ way, which is better than the errors I was getting before (No C++ compiler installed on this system!) It even got far enough to include some files that were #included in the code...
I noticed that the filename of this new gcc is arm-thumb-elf-gcc, which isn't quite the same as the old arm-agb-elf-gcc, which may or may not be significant... the new distribution also seems to be lacking an assembler and linker, or something... perhaps combining the assembler and linker from one package with the compiler from the other was a bad idea... man, I wish I knew what I was doing... It wasn't too long ago that I had no idea what the makefile did...
#16547 - poslundc - Thu Feb 19, 2004 6:19 am
Phroo, that seems weird... it almost looks as if it is generating the proper assembly code, but then calling the incorrect version of GAS or something.
In any case, this is out of my league. I'm going to suggest that you do a clean install of gcc (the newer version I suppose, since you want to use g++) and see if you can get it just compiling simple programs without using the compilcated makefile (I know the one with GBASDK, while very well-written, can complicate things more than it helps when you're trying to debug your compile process).
Dan.
#16590 - shaktool - Fri Feb 20, 2004 1:41 am
No luck yet, although I've tried a bunch of things. Some of things I tried ALMOST worked... like trying to compile the Linux version of the DevKit Advance source code with Make, or Babelfishing this page:
http://home.r00.itscom.net/top/gbcube/buildtools.html
But I always got to some sort of error that I didn't know what to do about. It's really too bad that it's so hard to find a C++ GBA compiler for Mac...
P.S. running the new gcc without a makefile causes the same errors... so I don't think it's assembling anything incorrectly, because it doesn't even get far enough to have anything to assemble. Those ARE suspicious error messages, though.
#16612 - Touchstone - Sat Feb 21, 2004 12:05 am
Check out this page, http://www.deadcoderssociety.tk/, in the GP32 section you can find an ARM gcc crosscompiler, I think it has C++ support.
_________________
You can't beat our meat
#16642 - shaktool - Sat Feb 21, 2004 8:53 pm
Whee! Thanks, Touchstone!
I'm still getting errors when I try to run g++, but they sound like errors I might be able to deal with, and the gcc that came with it works like a charm, which is promising. I think I'm okay now.
:)
-Shaktool
#16680 - shaktool - Sun Feb 22, 2004 6:40 pm
On second thought....
Alright, so I was able to get the version of g++ Touchstone suggested to compile my old C program as a .cpp file, and the resulting ROM ran perfectly. Then I started to use some C++ features... you know, classes and virtual functions... and I got these errors at the linking stage:
./build/foo.o(.gnu.linkonce.d._ZTI5Grace+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
./build/foo.o(.gnu.linkonce.d._ZTI6entity+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
Hmm, sounds to me like I need to be adding some C++ support libraries? Well, I made sure that, in my makefile, I passed to the linker the paths to the lib directories that came with my newest version of gcc, like this:
STD_LIB_DIR2 = /usr/share/gp32/arm-elf/lib
STD_LIB_DIR3 = /usr/share/gp32/lib/gcc-lib/arm-elf/3.0.4
./build/foo.elf : ./build/crt0.o ./build/foo.o
/usr/share/gp32/arm-elf/bin/ld ./build/crt0.o ./build/foo.o -o$@ -L$(STD_LIB_DIR2) -L$(STD_LIB_DIR3) -T ./lnkscript -lgcc
That didn't solve the problem. Hmmm....! Hey, I remembered seeing something in the crt0.s file that said you should uncomment something to enable C++ support... like this:
@ Uncomment the following line to support C++ development.
@ You also need to name your main C function the following:
@ int main (void) ...instead of... int AgbMain (void)
@ Doing so will cause ~5500 bytes of c++ support code to be
@ linked in with your project so do not enable c++ support
@ unless you plan to use it.
@ .equ __CPPSupport, 1
So I did, and I renamed my AgbMain to main.... Err... not only did that fail to solve my problem, it created tons of new errors... like this:
./build/NinjaParty.o(.gnu.linkonce.d._ZTI5Grace+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
./build/NinjaParty.o(.gnu.linkonce.d._ZTI6entity+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/share/gp32/lib/gcc-lib/arm-elf/3.0.4/libgcc.a(__main.o): In function `__do_global_dtors':
__main.o(.text+0x74): undefined reference to `__EH_FRAME_BEGIN__'
/usr/share/gp32/lib/gcc-lib/arm-elf/3.0.4/libgcc.a(__main.o): In function `__do_global_ctors':
__main.o(.text+0xc4): undefined reference to `atexit'
__main.o(.text+0x100): undefined reference to `__EH_FRAME_BEGIN__'
/usr/share/gp32/lib/gcc-lib/arm-elf/3.0.4/libgcc.a(unwind-dw2-fde.o): In function `size_of_encoded_value':
unwind-dw2-fde.o(.text+0x5c): undefined reference to `abort'
/usr/share/gp32/lib/gcc-lib/arm-elf/3.0.4/libgcc.a(unwind-dw2-fde.o): In function `read_encoded_value_with_base':
unwind-dw2-fde.o(.text+0x1d8): undefined reference to `abort'
/usr/share/gp32/lib/gcc-lib/arm-elf/3.0.4/libgcc.a(unwind-dw2-fde.o): In function `__register_frame':
unwind-dw2-fde.o(.text+0x274): undefined reference to `malloc'
(snip)
Anyone got any ideas?
p.s. Is anyone interested in how my last game turned out? Perhaps I should donate it as a demo to gbadev...