#27509 - SmegPlaza - Thu Oct 14, 2004 1:15 pm
Hi,
I've tried posting in the Coding forum but, apart from some really good help from DiscoStew, I've had a limited response. So I'm trying here...
I've got DevKitARM R8 and am trying to set up a build of mixed C and assembler files, using the GCC, AS and LD tools (as opposed to a trivial build with one C file, compiled and linked by a single call to GCC).
I can get compilation and assembly to work fine, but linking seems to be a problem...
Here's a much simplified version of my makefile (if it doesn't work, go back to basics right ?!):
| Code: |
PATH=C:\temp\stuff\gba\devkitarm\arm-elf
TOOLPATH=$(PATH)\bin
LIBPATH=$(PATH)\lib\interwork
CC=$(TOOLPATH)\gcc.exe
CFLAGS=-c -mthumb-interwork
LINK=$(TOOLPATH)\ld.exe
LFLAGS=-L$(LIBPATH) -marmelf
main.elf: main.o
$(LINK) $(LFLAGS) -omain.elf main.o $(LIBPATH)\crt0.o $(LIBPATH)\libc.a
main.o: main.c
$(CC) $(CFLAGS) -omain.o main.c |
As I said, compiling is fine.
Linking throws up the following errors though:
| Code: |
C:\temp\stuff\gba\devkitarm\arm-elf\lib\interwork\crt0.o(.text+0xdc): In function `start':
: undefined reference to `_init'
C:\temp\stuff\gba\devkitarm\arm-elf\lib\interwork\crt0.o(.text+0xfc): In function `start':
: undefined reference to `_fini' |
I'm obviously missing some vital piece of info...
Can anyone tell me where I'm going wrong please ???
Thanks in advance,
Smeg
#27512 - Lord Graga - Thu Oct 14, 2004 2:41 pm
first of all, don't point your TOOLPATH to devkiarm/arm-elf/bin, but devkitarm/bin.
second, try to add: --specs=gba.specs to your linking stage.
#27521 - sajiimori - Thu Oct 14, 2004 6:36 pm
Anybody who reads one of Coding/C++/Beginners will probably read all of them, so there's no need to make extra threads. There's no "trick" for getting responses, besides having a question that people know the answer to.
#27522 - DiscoStew - Thu Oct 14, 2004 6:37 pm
By the look on those linking errors, it seems that you are trying to compile and link C++ code with a C compiler/linker. I've had that problem before, which means you probably have int main(void) as your entry point. Changing it to int AgbMain(void) should fix those 2 linking problems.
I PMed you on things you asked about, which should allow you to try the Makefile I posted in the last thread.
_________________
DS - It's all about DiscoStew
#27538 - Cearn - Fri Oct 15, 2004 12:42 am
| SmegPlaza wrote: |
| Code: | PATH=C:\temp\stuff\gba\devkitarm\arm-elf
TOOLPATH=$(PATH)\bin
LIBPATH=$(PATH)\lib\interwork
CC=$(TOOLPATH)\gcc.exe
CFLAGS=-c -mthumb-interwork
LINK=$(TOOLPATH)\ld.exe
LFLAGS=-L$(LIBPATH) -marmelf
|
|
If I try to rewrite my (working) makefiles to use these commands I get the same undefined _init and _fini as you do. I got rid of these errors by linking with gba_crt0.o instead of ctr0.o, but only got more mystifing errors in return.
The thing about linking with ld directly is that you have to specify each and every detail of the linking process yourself. You can save yourself a world of hurt by using gcc instead, which chooses the right directories, start-up files and libraries for you. You will have to tell it that you're building a GBA binary by using either -specs=gba.specs (one hyphen) or -specs=gba_mb.specs for a multiboot game. Also, like Graga said, it might be better to use the commands in devkitarm/bin instead of devkitarm/arm-elf/bin. Note that these all have the 'arm-elf-' prefix, though.
The makefile will then look something like
| Code: |
# if you attach the BINDIR to the system apth, you won't have
# to define and use it here anymore
BINDIR = c:/temp/stuff/gba/devkitarm/bin
CROSS = arm-elf-
CC = $(BINDIR)/$(CROSS)gcc
LD = $(BINDIR)/$(CROSS)gcc
OBJCOPY = $(BINDIR)/$(CROSS)objcopy
CFLAGS = -c -mthumb-interwork
LDFLAGS = -specs=gba.specs
# --- convert to GBA rom ---
main.gba : main.elf
$(OBJCOPY) -v -O binary main.elf main.gba
gbafix main.gba
# --- link ---
main.elf: main.o
$(LD) $(LDFLAGS) -o main.elf main.o
# --- compile ---
main.o: main.c
$(CC) $(CFLAGS) -o main.o main.c
|
#27576 - wintermute - Fri Oct 15, 2004 11:15 pm
| DiscoStew wrote: |
By the look on those linking errors, it seems that you are trying to compile and link C++ code with a C compiler/linker. I've had that problem before, which means you probably have int main(void) as your entry point. Changing it to int AgbMain(void) should fix those 2 linking problems.
I PMed you on things you asked about, which should allow you to try the Makefile I posted in the last thread. |
those two linking problems have nothing to do with the name of the main function. They're entirely due to not specifying all the required object files when linking.
The simplest way is to use arm-elf-gcc as the linker and use the -specs switch.
For a cart image use -specs=gba.specs
for a multboot image use -specs=gba_mb.specs
#27584 - DiscoStew - Sat Oct 16, 2004 1:33 am
I've had problems with the undefined references to "_init" and "_fini" before, and changing the entry point name from "int main(void)" to "int AgbMain(void)" had fix those problems for me in an old project of mine. I only suggested that change because it had worked for me. If that isn't meant to fix those problems, what does using "AgbMain" instead of "main" do?
_________________
DS - It's all about DiscoStew
#27601 - wintermute - Sat Oct 16, 2004 6:46 pm
| DiscoStew wrote: |
| I've had problems with the undefined references to "_init" and "_fini" before, and changing the entry point name from "int main(void)" to "int AgbMain(void)" had fix those problems for me in an old project of mine. I only suggested that change because it had worked for me. If that isn't meant to fix those problems, what does using "AgbMain" instead of "main" do? |
it names your main function AgbMain instead of main :P
DevkitAdvance was patched so that AgbMain inserts code to call global constructors. With DevkitARM this is done by the crt0 and specs files instead.