#69436 - Kaiser - Mon Jan 30, 2006 7:44 pm
I've been experimenting with GBA development for a while, and I was wondering how I can setup Visual C++ 6.0 to use devkitARM to compile my gba roms? I've been using a .bat file to compile but its getting really tedious.
I appriciate any feedback.
#69458 - Cearn - Mon Jan 30, 2006 9:29 pm
Tonc: setup: MS Visual C++ makefile projects. There are easier ways with later devkitARMs (the page was written when r6 was still current), but the information is still valid.
There's one at the devkitpro site too.
#69478 - Kaiser - Tue Jan 31, 2006 12:43 am
Thanks.
I configured my devKitPro settings in my enironment variables and configured Visual C. After I finished, I copied and pasted the makefile that came with DevKitPro into my project folder.
When I try to compile my rom, I get this error:
--------------------Configuration: GBAPROJECT - Win32 Release--------------------
linking cartridge
e:/devkitpro/devkitarm/bin/../lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/thumb/interwork/gba_crt0.o: In function `start_vector':
gba_crt0.s:(.init+0x220): undefined reference to `main'
make[1]: *** [/e/devkitPro/GBAPROJECT/GBAPROJECT.elf] Error 1
make: *** [build] Error 2
GBAPROJECT.gba - 2 error(s), 0 warning(s)
I can't seem to find where this issue is comming from.
#69605 - tepples - Tue Jan 31, 2006 7:42 pm
"undefined reference to main" means that none of your source code files contains a publicly visible main() function. Which file contains main(), and are you sure it's getting linked into your project?
(RANT: That's another reason why I don't like wintermute's makefile: it hides the command line, making it harder to debug invocation issues.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#69668 - Kaiser - Wed Feb 01, 2006 1:37 am
I've checked everything in the makefile and made sure that my main c file is included. I changed a few paths (mainly the source path and the include path) and I got past the error.. but now got another one.
Here is a link to my test project if interested in checking out
http://vault.d3files.com/temp/GBAPROJECT.zip
The error message is in the file error.txt
Again I appricate your help.
#69706 - Cearn - Wed Feb 01, 2006 12:40 pm
Well, I got a partial solution to your problem.
First of all, SOURCES should contain the source directories, not the names of the source files themselves. Also, don't specify paths the Windows way, do it like this: "/e/devkitpro/GBAPROJECT". Forward slashes, no trailing slash (I think), and case-sensitive. Actually, it's better to use relative paths instead of absolute ones. Look to the example makefiles to see how that's done.
However, once I did that I may have gotten rid of the make errors, but I got stuck in an endless loop of makes. Thing is, these makes run recursively and I've been unable to make them stop. I know the stopping condition concerns this line
| Code: |
ifneq ($(BUILD),$(notdir $(CURDIR)))
|
But for some reason I just can't get it to work correctly at this time. Sorry.
#70697 - wintermute - Wed Feb 08, 2006 7:40 am
| Code: |
#---------------------------------------------------------------------------------
# Clear the implicit built in rules
#---------------------------------------------------------------------------------
.SUFFIXES:
#---------------------------------------------------------------------------------
ifeq ($(strip $(DEVKITARM)),)
$(error "Please set DEVKITARM in your environment. export DEVKITARM=<path to>devkitARM)
endif
include E:\devkitPro\devkitARM\gba_rules
#---------------------------------------------------------------------------------
# TARGET is the name of the output, if this ends with _mb a multiboot image is generated
# BUILD is the directory where object files & intermediate files will be placed
# SOURCES is a list of directories containing source code
# DATA is a list of directories containing data files
# INCLUDES is a list of directories containing header files
#---------------------------------------------------------------------------------
TARGET := $(shell basename $(CURDIR))
BUILD := E:\devkitPro\GBAPROJECT\
SOURCES := pixelTest.c
DATA :=
INCLUDES := E:\devkitPro\GBAPROJECT\include
|
1. You shouldn't have changed "include $(DEVKITARM)/gba_rules" to "include E:\devkitPro\devkitARM\gba_rules". If this didn't work as written then you probably set DEVKITARM wrong, it should be "/e/devkitPro/devkitARM" - this is documented at http://www.devkitpro.org/setup.shtml
2. The other variables are all specified relative to the Makefile, you should *not* place full paths there. The variables should have been set as follows, note the use of "." ( a single period) to specify the directory in SOURCES - this tells the Makefile that the sources are in the same directory.
| Code: |
TARGET := $(shell basename $(CURDIR))
BUILD := build
SOURCES := .
DATA :=
INCLUDES := include
|
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#75392 - gmiller - Sun Mar 12, 2006 5:50 pm
The makefile commands that you want to be visable to see how the files are compiled are in the base_rules file in the devkitARM folder. Just remove the '@' that begins the commands to make them visable when they execute. Make sure you just remove the @ at the begining of the command:
For example:
@$(CC) -MMD -MF $(DEPSDIR)/$*.d $(CFLAGS) -c $< -o $@
needs to become:
$(CC) -MMD -MF $(DEPSDIR)/$*.d $(CFLAGS) -c $< -o $@
Be sure that the line begins with a tab character (not spaces) or the make utility will process the line. As I was debugging changes to the files to fit how my class would use these files I needed to see what it was doing. I now use my version of the make files to compile from visual ham and to debug from the msys command prompt.
#76279 - gmiller - Mon Mar 20, 2006 3:28 am
I have been doing experiments settin up VS 2003 .NET to work with the devkitPro devkitARM setup and have found that I can not get it to work but the same setup with VS 2005 works perfectly. The other issue I have foun is that if you want to do source code debugging with either gdb/DDD/insight etc ... then do not use any version of vba SDL newer than 1.7.1. The issues with souce level debuggin were introduced some time after that release. I have tried multiple combinationn from many environments and the answer is that only for 1.7.1 and back does the interface that these debuggers talk to work.
#76557 - wintermute - Wed Mar 22, 2006 6:40 pm
How did you set up .net 2003? I don't have this particular version unfortunately but VS6 and 2k5 work perfectly here. I'm also told that .net 2003 works fine for others after converting a VS6 project - there are a couple in the gba examples.
As for Insight and VBA I've been using 1.8.0 with Insight 6.4.5 for a while with few problems - on windows, I haven't yet looked at using them in linux. What issues are you getting?
Quite a few people have been asking about how to show the actual command lines being used for compiling. I've updated the base_rules file so all these will be shown for release 18 - due any day now, still a bit of testing to do atm.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog