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 > Compilation problem in Linux

#142754 - Phantaseur - Fri Oct 12, 2007 6:38 pm

I changed my OS to linux and now trying recompile all of my projects. But there is problem at final stage, every time ndstool returns error
Code:
/usr/home/ndscoder/nds/devkitpro/devkitARM/bin/ndstool -c project.nds -9 project9.bin -7 project7.bin
*** Error code 127

Stop in /usr/home/ndscoder/nds/ndsdev/projects/proj1.
There is no explanation what is error 127 and how can I solve it. In windows all works normall.
I hope anybody will help me, I don't want return to old OS.

#142851 - tondopie - Sun Oct 14, 2007 4:53 pm

did you set up devkitpro for your environment? Did you add the devkitpro and devkitARM paths to your .bashrc?

#143045 - Phantaseur - Tue Oct 16, 2007 10:31 am

No, I just wrote full paths in makefile...
Which global vars need I set up?

#143101 - tondopie - Tue Oct 16, 2007 9:54 pm

open your .bashrc file and add this to the end:

Code:
export DEVKITPRO=/home/max/devkitpro
export DEVKITARM=$DEVKITPRO/devkitARM
export PATH=$DEVKITARM/bin:$PATH
export PAPATH=DEVKITPRO/PAlib


obviously replace "max" with what ever your username is. Also you don't need the last line if you are not using PAlib.


EDIT: Also set the DEVKITPRO varable to a different directory if its not in your HOME folder

make sure you have the cases right, too!

#143128 - tepples - Wed Oct 17, 2007 5:03 am

tondopie wrote:
Code:
export PATH=$DEVKITARM/bin:$PATH
export PAPATH=DEVKITPRO/PAlib


The first two lines (setting DEVKITPRO and DEVKITARM variables) are fine, but ideally, the makefile should set PATH and PAPATH, not .bashrc. Relevant lines from $DEVKITPRO/examples/gba/template/Makefile are as follows:

Code:
ifeq ($(strip $(DEVKITARM)),)
$(error "Please set DEVKITARM in your environment. export DEVKITARM=<path to>devkitARM)
endif

# ...

export PATH   :=   $(DEVKITARM)/bin:$(PATH)

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#143444 - Hyouko - Sun Oct 21, 2007 7:11 pm

I'm running into a similar problem after updating to Ubuntu 7.10 today; I was running Feisty previously, and didn't have any trouble compiling. I've got the appropriate environment variables set (I was taught to set them under /etc/environment, seems to work); the code compiles successfully and creates .elf/.arm9 files, but make barfs inexplicably right after that, like so:

Code:

linking Dove.elf
built ... Dove.arm9
make[1]: *** [/home/XXXXXX/NDS/Dove/Dove.nds] Error 127
make: *** [build] Error 2


Any idea what's up?

edit: Googling tells me that make error 127 occurs when make can't find a tool needed to execute a command. Hrm. In my last (very messy) install of devkitARM, I installed r20 straight over r19; any chance that there's some files left out of r20 that were supplied by the r19 install?

edit the second: no dice. this'd be easier if I could get it to tell me which tool it's not finding!

#143448 - tepples - Sun Oct 21, 2007 9:43 pm

Hyouko wrote:
Code:

linking Dove.elf
built ... Dove.arm9
make[1]: *** [/home/XXXXXX/NDS/Dove/Dove.nds] Error 127
make: *** [build] Error 2

[...]

this'd be easier if I could get it to tell me which tool it's not finding!

When the commands in rules used by the template makefile have an @ sign in front of them, GNU Make will not echo the command. Try doing this:
  1. Copy the file ds_rules from .../devkitPro/devkitARM/ to the folder containing your project's makefile.
  2. In your project's makefile, change
    include $(DEVKITARM)/ds_rules
    to
    include ./ds_rules
  3. In the copy of ds_rules in your project's folder, remove the @ signs before command names such as dsbuild and ndstool.

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#143458 - Hyouko - Sun Oct 21, 2007 10:48 pm

...Guess that wasn't as helpful as I'd hoped:

Code:

built ... Dove.arm9
ndstool -c /home/XXXXX/NDS/Dove/Dove.nds -9 /home/XXXXXX/NDS/Dove/Dove.arm9
make[1]: *** [/home/XXXXXXX/NDS/Dove/Dove.nds] Error 127
make: *** [build] Error 2


ndstool is definitely there. It's complaining, best as I can tell, that the .nds file isn't there, which is true - ndstool hasn't made it yet. Could the makefile be trying to build stuff out of order for some reason?

Upon trying to compile the textured cube example, I got this error:

Code:

make[1]: *** No rule to make target `texture.o', needed by `/home/XXXXXXX/NDS/Examples/Graphics/3D/Misc/Textured_Cube/Textured_Cube.elf'.  Stop.


which is strange, because I based the code for my own project off of this to begin with, and it doesn't seem to stumble over the textures for that...

#143523 - djupdal - Tue Oct 23, 2007 8:44 am

Hyouko wrote:
ndstool is definitely there. It's complaining, best as I can tell, that the .nds file isn't there, which is true - ndstool hasn't made it yet. Could the makefile be trying to build stuff out of order for some reason?

I got similar problems when I upgraded to Gutsy. My solution was to recompile ndstool (found sources on sourceforge). Now it works correctly again.

#143537 - teh_programerer - Tue Oct 23, 2007 3:29 pm

djupdal wrote:
Hyouko wrote:
ndstool is definitely there. It's complaining, best as I can tell, that the .nds file isn't there, which is true - ndstool hasn't made it yet. Could the makefile be trying to build stuff out of order for some reason?

I got similar problems when I upgraded to Gutsy. My solution was to recompile ndstool (found sources on sourceforge). Now it works correctly again.


I did just that (after upgrading from Feisty to Gutsy) and nothing happened, well, it didn't work. I then compiled the dsbuild binary as well, that did the trick.
_________________
C allows you to shoot yourself in the foot rather easily. C++ allows you to re-use the bullet!

#143544 - Hyouko - Tue Oct 23, 2007 5:36 pm

teh_programerer wrote:
djupdal wrote:
Hyouko wrote:
ndstool is definitely there. It's complaining, best as I can tell, that the .nds file isn't there, which is true - ndstool hasn't made it yet. Could the makefile be trying to build stuff out of order for some reason?

I got similar problems when I upgraded to Gutsy. My solution was to recompile ndstool (found sources on sourceforge). Now it works correctly again.


I did just that (after upgrading from Feisty to Gutsy) and nothing happened, well, it didn't work. I then compiled the dsbuild binary as well, that did the trick.


Any chance you folks could share those binaries? I'm having a hell of a time getting any of the DevKitPro stuff from SourceForge to build - the latest build script seems to be looking to download several source packages that don't actually exist yet.

#143547 - teh_programerer - Tue Oct 23, 2007 6:54 pm

Hyouko wrote:
Any chance you folks could share those binaries? I'm having a hell of a time getting any of the DevKitPro stuff from SourceForge to build - the latest build script seems to be looking to download several source packages that don't actually exist yet.


Here you go. The source is included, too, just in case it may work.
_________________
C allows you to shoot yourself in the foot rather easily. C++ allows you to re-use the bullet!

#143551 - Hyouko - Tue Oct 23, 2007 7:47 pm

teh_programerer wrote:
Hyouko wrote:
Any chance you folks could share those binaries? I'm having a hell of a time getting any of the DevKitPro stuff from SourceForge to build - the latest build script seems to be looking to download several source packages that don't actually exist yet.


Here you go. The source is included, too, just in case it may work.


Worked wonderfully - thanks! And it looks like I was trying to build a lot more than I needed to (devkitARM from scratch, rather than just ndstool and dsbuild). Since devkitARM r21 is going out, I guess I shouldn't be surprised that lots of things are moving around and/or potentially not working at the moment.