gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > scary warning at link

#87380 - yanos - Tue Jun 13, 2006 5:55 pm

I have a warning during link that I don't really like:

Code:

main.cpp
arm-eabi-g++ -MMD -MP -MF ./build/main.d -Wall -O2 -fno-exceptions -fno-rtti -mcpu=arm9tdmi -mtune=arm9tdmi -I/opt/devkitpro/libnds/include -DARM9 -c main.cpp -o main.o
dsSprite.cpp
arm-eabi-g++ -MMD -MP -MF ./build/dsSprite.d -Wall -O2 -fno-exceptions -fno-rtti -mcpu=arm9tdmi -mtune=arm9tdmi -I/opt/devkitpro/libnds/include -DARM9 -c dsSprite.cpp -o dsSprite.o
linking test.arm9
/opt/devkitpro/devkitARM/bin/arm-eabi-ld.real: warning: cannot find entry symbol cs=ds_arm9.specs; defaulting to 00008000

If I remove -specs=ds_arm9.specs from LDFLAGS, it won't be able to find _start, witch scares me even more. Before, I was doing gba developpement and you had to supply a linkscript and a the ctr0.o object file. I'm not sure how to proceed with the ds.

Here is my Makefile:
Code:

include $(DEVKITARM)/ds_rules

export LD       := $(PREFIX)ld

CFLAGS          := -Wall -O2 -fno-exceptions -fno-rtti -mcpu=arm9tdmi -mtune=arm9tdmi -I$(DEVKITPRO)/libnds/include -DARM9
CXXFLAGS        := $(CFLAGS)
LIBPATHS        := -L$(DEVKITARM)/lib -L$(DEVKITPRO)/libnds/lib
LIBS            := -lnds9
LDFLAGS         := -specs=ds_arm9.specs
DEPSDIR         := ./build
OFILES          := main.o dsSprite.o

all: test.nds

test.arm9:$(OFILES)

clean:
        rm -f *.o


I am trying to build with devkitpro19 and the latest libnds.

#87397 - silent_code - Tue Jun 13, 2006 8:18 pm

try to use the makefile and folder layout that the examples use. try to compile one of the examples and if everything is fine (what should happen normally) just replace everything with your files (in a copy of the example) and try to compile that. should compile and link fine. beware, emulators won't run r19 code. you'll have to test it on hw.

sorry, i can't help you any further.

good luck!

ps: with the default makefile you just start make and have you rom. no need to modify it (that's why you'll have to use the special folder layout - shouldn't be a problem).

#87431 - wintermute - Tue Jun 13, 2006 10:18 pm

-fno-exceptions and -fno-rtti aren't valid CFLAGS, these should be placed in CXXFLAGS.

Don't use ld directly for linking, use gcc (or g++ for C++ code)
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#87462 - yanos - Wed Jun 14, 2006 12:58 am

Ok, I've found the examples you were talking about. There isn't much else to say, everything works just fine now :)

As for emulator not able to run code from devkitpro19, I was under the impression that the only thing that had changed was the abi, so with my (limited) understanding it would have cause incompatibility between binary and library of different abi only. Anyway, it's not that important since I was planing to test on real hardware...

#87474 - wintermute - Wed Jun 14, 2006 2:10 am

the problems I've heard about appear to be related to unemulated arm946e-s instructions - this should only be a problem when using -march=armv5te -mtune=arm946e-s but I've heard vague reports of this cropping up with arm9tdmi.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#87479 - silent_code - Wed Jun 14, 2006 2:43 am

i'm happy it works now! :) happy coding!



wintermute wrote:
the problems I've heard about appear to be related to unemulated arm946e-s instructions - this should only be a problem when using -march=armv5te -mtune=arm946e-s but I've heard vague reports of this cropping up with arm9tdmi.


i admit i Don't understand it in detail, but i get the general spin of the problem...

so it is (like tepples already said elsewhere) up to the emu authors to fix it and make r19 based roms work... i stepped back to r18 until that happens as i want to be able to test and debug my code more comfortably and check for compatibility issues (between buggy emus and real hardware) after the code appears to work in different emus (i still have to send it to other ppl to check it on hw... :( ).
sending a rom to the nds and running it there (without debug tools - ok, you can put some of your own into the rom, but that changes the whole program and may affect performance...) every time you build it, is a bit unproductive, imo. though i know the hw test is simply crucial, because that is the target you build your code for (tepples had a fine quote), it is pretty time consuming and having no emulation hardware (e.g. the nitro hw emulator), software emus are the less evil.

ok, this is getting sort of offtopic. let's hope dualis & co. get updated and run r19 based code properly... at least so the programs resulting behaviour is the same as on hw.

greetings to all you out there!