#8239 - hnager - Sat Jul 05, 2003 2:57 am
And here I thought that I had the STL linking properly - the following compiles without error, but running it kicks back the errors described below (from the Mappy Console). The makefile is also included below. THanks for any help - Howard:
//THE SOURCE
#include "gba.h"
#include <vector>
extern "C" int write( int fh, const void *buf, unsigned cnt ){
return 0 ;
}
void foo() {
std::vector<int> intvect;
intvect.push_back(42);
}
int main(){
foo();
return 0;
}
//AND...THE ERRORS
Mappy VM: Logging started on 7/4/2003 9:47:41 PM
PlatformSound: Creating DirectSound interface
Loading external BIOS "C:\GAME_DEV\GBA_TOOLS\mappyvm_0.9d\v0.bios"
Loading cartridge info from POLYGON.sav
Unimplemented opcode at $08019298: LDM with forced user bank
Unimplemented opcode at $080192B4: LDM with forced user bank
ROM[080192B4]=00000004 at 080192B4
ROM[080192B8]=03007E3C at 080192B4
ROM[080192BC]=00000000 at 080192B4
...
//THE MAKEFILE - I'm guessing that I'm doing something wrong here
PATH=c:\DevKitAdv\bin;
DEVDIR = c:\DevKitAdv
LIBDIR = $(DEVDIR)\lib\gcc-lib\arm-agb-elf\3.0.2\interwork
LIBDIR2 = $(DEVDIR)\arm-agb-elf\lib\interwork
NAME = POLYGON
CFLAGS = -c -O3
LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T lnkscript
MODEL = -mthumb -mthumb-interwork
$(NAME).bin : $(NAME).elf
objcopy -O binary $(NAME).elf $(NAME).bin
$(NAME).elf : crt0.o crtbegin.o crtend.o main.o
ld -nostartfiles $(LDFLAGS) -o $(NAME).elf crt0.o crtbegin.o crtend.o main.o -lstdc++ -lgcc -lc -lgcc
main.o : main.cpp
g++ $(CFLAGS) $(MODEL) main.cpp
crt0.o : crt0.s
g++ $(CFLAGS) $(MODEL) crt0.s
#8243 - tepples - Sat Jul 05, 2003 6:21 am
Does it work in VisualBoyAdvance? Some emulators just haven't implemented all opcodes yet; my tests show that Mappy VM isn't nearly as accurate as VBA.
GCC 3.0.2 is said to have problems at optimization level -O3. Change to -O2, or (better yet) upgrade to DevKit Advance R5 beta 3, which includes GCC version 3.2.2 that has fixed many ARM backend bugs. In fact, you may not even need a custom link script and crt0 with DKA5.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#8250 - hnager - Sat Jul 05, 2003 12:22 pm
I don't get the all of those errors in VisualBoy Advanced, however in a seperate test I traced out some text to the console (logging...) window - only the text before the vector initialization and initial push_back() showed up in the console.
I will try your suggestions - I reverted back to using an earlier release of devkit because I get the error that -lgcc cannot be found when using the new beta/release.
#8251 - hnager - Sat Jul 05, 2003 12:53 pm
Changing the optimization level to -02 seemed to have helped n- at first...but as soon as I push_back() a second value it won't trace out anymore to the console window.
Simply changing it to point to devkit r5b3 gives me this error at compiletime:
ld -nostartfiles -L c:\GBA\lib\gcc-lib\arm-agb-elf\3.2.2\interwork -L c:\GBA\arm-agb-elf\lib\interwork -T lnkscript -o POLYGON.elf crt0.o crtbegin.o crtend.o main.o -lstdc++ -lgcc -lc -lgcc
c:\GBA\arm-agb-elf\lib\interwork\libc.a(agb-sbrk.o): In function `_sbrk':
../../../../../../../gcc-3.2.2/newlib/libc/sys/agb/agb-sbrk.c:28: undefined reference to `__appended_end'
../../../../../../../gcc-3.2.2/newlib/libc/sys/agb/agb-sbrk.c:28: undefined reference to `__heap_limit'
../../../../../../../gcc-3.2.2/newlib/libc/sys/agb/agb-sbrk.c:28: undefined reference to `__appended_start'
Any other attempt to remove the linkscript or use gcc/g++ as opposed to ld gives me a huge list that looks like:
c:\GBA\bin\..\lib\gcc-lib\arm-agb-elf\3.2.2\..\..\..\..\arm-agb-elf\bin\ld.exe: Warning: c:\GBA\bin\..\lib\gcc-lib\arm-agb-elf\3.2.2\..\..\..\..\arm-agb-elf\lib\libstdc++.a(functexcept.o) does not support interworking, whereas POLYGON.elf does
Thanks to everybody for the help so far - I feel as if I'm very close to this working...hopefully somebody will see something in these errors which will show what I'm doing wrong.
#8252 - tepples - Sat Jul 05, 2003 5:15 pm
| hnager wrote: |
Simply changing it to point to devkit r5b3 gives me this error at compiletime:
ld -nostartfiles -L c:\GBA\lib\gcc-lib\arm-agb-elf\3.2.2\interwork -L c:\GBA\arm-agb-elf\lib\interwork -T lnkscript -o POLYGON.elf crt0.o crtbegin.o crtend.o main.o -lstdc++ -lgcc -lc -lgcc
c:\GBA\arm-agb-elf\lib\interwork\libc.a(agb-sbrk.o): In function `_sbrk':
../../../../../../../gcc-3.2.2/newlib/libc/sys/agb/agb-sbrk.c:28: undefined reference to `__appended_end'
../../../../../../../gcc-3.2.2/newlib/libc/sys/agb/agb-sbrk.c:28: undefined reference to `__heap_limit'
../../../../../../../gcc-3.2.2/newlib/libc/sys/agb/agb-sbrk.c:28: undefined reference to `__appended_start' |
These were new symbols introduced in the new startup code in DKA5 beta 3.
| Quote: |
Any other attempt to remove the linkscript or use gcc/g++ as opposed to ld gives me a huge list that looks like:
c:\GBA\bin\..\lib\gcc-lib\arm-agb-elf\3.2.2\..\..\..\..\arm-agb-elf\bin\ld.exe: Warning: c:\GBA\bin\..\lib\gcc-lib\arm-agb-elf\3.2.2\..\..\..\..\arm-agb-elf\lib\libstdc++.a(functexcept.o) does not support interworking, whereas POLYGON.elf does |
Fix this by using -mthumb -mthumb-interwork when calling g++ to link. This will link in the Thumb interworking version of the C and C++ standard libraries, rather than the default ARM non-interworking version.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#8255 - hnager - Sat Jul 05, 2003 6:31 pm
Well - my makefile is down to:
PATH=c:\GBA\bin;
DEVDIR = c:\GBA
NAME = POLYGON
CFLAGS = -c -O3
LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T lnkscript
MODEL = -mthumb -mthumb-interwork
$(NAME).bin : $(NAME).elf
objcopy -O binary $(NAME).elf $(NAME).bin
$(NAME).elf : main.o
g++ $(MODEL) -o $(NAME).elf main.o -lstdc++
main.o : main.cpp
g++ $(CFLAGS) $(MODEL) main.cpp
using dka5b3 and the standard crt* files...everything compiles fine, however as soon as I introduce a vector the rom doesn't run as it's supposed to. None of the mappy console traces show up.
#8287 - Jason Wilkins - Mon Jul 07, 2003 5:10 am
There is a known issue with using STL, -mthumb and -mthumb-interwork.
This is probably due to a problem with linking the thumb version of libstdc++.a, so as a workaround, when you link, do not specify -mthumb.
_________________
http://devkitadv.sourceforge.net
#8290 - hnager - Mon Jul 07, 2003 11:29 am
It may be a dream - it's not even 6:30am where I am...but it looks as if - it works!
I created a vector, added some elements with push_back() and then traced out the length of the vector - all without error - here is where I ended up with on the makefile front using devkit r5b3:
PATH=c:\GBA\bin;
NAME = POLYGON
CFLAGS = -c -O3
$(NAME).bin : $(NAME).elf
objcopy -O binary $(NAME).elf $(NAME).bin
$(NAME).elf : main.o
g++ -o $(NAME).elf main.o -lstdc++
main.o : main.cpp
g++ $(CFLAGS) main.cpp
Thanks again for all the help - my next issue will hopefully be unrelated to the STL - vectors at least.
#8295 - Sweex - Mon Jul 07, 2003 2:19 pm
Good for you!:-)
And that is with the verison of STL that comes with devkitadvance, isn't it?