View Full Version : FPC4NDS and depending devkitpro versions

23-04-2010, 10:20 PM

Just wondering if someone could clear up a few queries? I was trying to get some documentation together about lazarus working with fp4nds - but in the mean time, a new release of devkitpro has been released - and the v27 is no longer of sourceforge. As a result, I've done some experimenting/digging and think the below info is correct.

The fp4nds 2.4.0 release ships with, compiled pascal import libaries for the various libnds libraries that we installed with devkitpro release 27 (ie those in the arm-nds\libndsfpc). According to http://www.devkitpro.org/category/devkitarm/ - release 27 shipped with :-
libnds 1.4.0
dswifi 0.3.11
libfat 1.0.6
default arm7 0.5.8
libfilesystem 0.9.4
(& gcc 4.4.2)

So obviuously we're tied to the above versions.

Now devkitarm is at release 30 - and sourceforge only seems to keep the past 3 realease - (30,29,28) - so 27 seems to have disspeared.

It appears that that the \fpc\2.4.0\bin\arm-nds folder is made up of :-
Most of the devkitarm (r27) C:\devkitPro\devkitARM\bin (including ndstool/mmutil etc),
Ppcarm.exe & fpc.exe

(Does ppcarm.exe invoke the fpc.exe (pascal->object code), then invokes the link (fpc\2.4.0\bin\arm-nds\arm-eabi-ld.exe) and then calls ndstool.exe)?

Anyway - what does appear to work is this.
1 Use the devkitpro installer - and get the latest devkitarm/libnds.
2 Get the prebuild libnds 1.4.0, dswifi 0.3.11, libfat 1.0.6, default arm7 0.5.8 and extract to a different folder (c:\nds\libnds)
3 Alter the fpc.cfg file to something like :-


invoking make OS_TARGET=nds CPU_TARGET=arm BINUTILSPREFIX=arm-eabi- PP=ppcarm.exe seems to build ok.

My real questions are :-

1 - The linker (arm-eabi-ld.exe) within the fpc\2.4.0\bin\arm-nds folder links to :-
libc.a ->C:\devkitPro\devkitARM\arm-eabi\lib
libgcc.a ->C:\devkitPro\devkitARM\lib\gcc\arm-eabi\4.4.3

Devkitarm (r27) was based on gcc 4.4.2 later versions are 4.4.3. Does it matter if were using a 4.4.2 linker version to link against libraries (lib.a etc) built with 4.4.3?

Likeise, there are other files (eg crt.a) - I assume the fpc4nds compiler magic is in system.pas that needs to link with these libraries? If there is such a version dependency, was there any reason why the corrseponing library files weren't in the fpc4nds 2.4.0 binary release?

2 - Ndstool shipped with fpc4nds is 1.46. The current shipped with v30 is 1.47.
It appears that ndstool uses the default.arm/default.elf it finds from the %devkitpro%\libnds folder. Using the above setup means that ndstool 1.46 is using the latest default.* file from the offical devkit folder. (Is there a compiler/library dependency with these default.* files?)

I think that about covers my queries. (Once I get answers to the above - I'll post fuller instructions on getting lazarus setup).



PS - Thanks to Legolas - I don't yet fully understand whats involved in this project but the amount of effort gone into this must be enormous!

24-04-2010, 07:24 AM
fpc.exe is the frontend. It'll invoke the ppc(cross)*.exe depending on which -Px architecture it's given.

I would be surprised if a minor version number change meant that much. Doesn't it work when you try to build with those versions?

Anyway, have you tried to build fpc from source against those new libraries?

24-04-2010, 12:55 PM
Unfortunately, every new DKA release breaks the compatibility with previous releases and adjusting fpc to be compliant to devkitARM requires some time. Just to clear things: r28 was released at February 25th 2010; r29 at March 23rd 2010; r30 at March 25th 2010.
The Freepascal team releases a new version every year or so and, till the fpc package manager will be released, I can't follow the DKA releases. However, some DKA releases (as r28, for example) require some changes to the compiler too, so the package manager is useless in these cases.

The svn trunk is compatible with r28, but I'm working on r30. I'm thinking about an "unofficial" fpc release, based on fixes_2_4 branch, in order to fix these problems...

24-04-2010, 04:28 PM
Can I just check that

1 - the fpc4nds 2.4.0 was based on devkitarm (r27).

2 - The \fpc\2.4.0\bin\arm-nds folder is made up of most of the devkitarm (r27) C:\devkitPro\devkitARM\bin (including ndstool/mmutil etc) + the fpc compiler(s).

3 - Now that devkitarm (r27) has dissapeared from sourceforge - is there another way to get the pre-built (r27) libraries that ppcarm links with, eg those in the


(Browsing the svn repro (https://devkitpro.svn.sourceforge.net/svnroot/devkitpro) I can't seem to find anything devkitarm related at all)

EDIT - I've actually found the buildscript directory - and think I've found the svn revison that built 27. I'm reading the readme/getting the other libraries and trying to compile devkitarm now.


PS If you are thinking of another release, would it possible to take whatever pre-build libraries your dependent on, and ship them with your installer?

30-04-2010, 10:01 AM
Just a thought. :S I went the other way around, because I am also unfortunate enough to have missed DKA_R27 :(.

- Installed DKA_R28 manually.
- Then I read between the lines of what Legolas said :) and directed my browser to
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/ and
and ofcourse downloaded appropiate/necessary sourcefiles
- added missing ?! input.inc include file which should be located at
- build
- et voila. With many great thanks to Legolas hard work I have now a compiled version of fpc4nds that seems to work ok with DKA_R28.

I say seem because I have not tested all examples yet. Only directory left to check for me is the graphics directory. All other examples did work on the emulator :)

So my question (sorry to bother you) for Legolas is: Am I correct in saying that I could not find the mentioned input.inc source from the svn or did I forgot to put on my binoculars ? :)


30-04-2010, 01:13 PM
I'm in the middle of an update, so the sources from SVN couldn't be ready for a direct build. Input.inc has been reworked a little bit, so now it is divided in two files (the first one in nds/ directory, the second one in the nds/arm9), but I haven't uploaded the latest changes to SVN yet.

I'm afraid that your setup could be wrong, because sometimes the RTL is updated according to changes in the compiler. For example, often the linker script and the crt0 are updated in devkitARM at the same time, but in freepascal the linker script is hard coded in the compiler itself. So rebuilding the rtl and the nds library is not always enough. A complete rebuild should be the right way :)

30-04-2010, 03:15 PM
Hi Legolas,

Thank you for your (quick) reply.

I really did not wanted to bother you because I know you are busy trying to update to R30 :S

Well I guess I cannot hide the fact anymore (wow that took me exactly 1 post) that I lived a luxurious live being an (sortof static) end-user in that matter. So I apologize beforehand being ignorant concerning the inner workings of fpc. Let alone in relation to your project. :-[

I'm afraid that your setup <snip> complete rebuild should be the right way

I do understand what you are saying (thanx for clearing that up for me), I was unaware of that fact.

It raises a question (well actually a couple of twenty to be honest) of which I think I am unable to answer on my own (so if I may ask if anybody would be so kind to give some pointers into the right direction I would appreciate that very much, i'm just trying to make sense out of all of this):

If the linker-script in the DKA was/is updated and therefor would not be compatible anymore linking against an older setup, wouldn't that raise issues (linking errors) whilst trying to compile such a project ? Or is the linker not smart enough to detect those kinds of pitfalls ? In other words how am I suppose to catch such an incompatibility issue ???

I did take a look at the C-sources of DKA_28 (yes i'm aware you are working on R30 so perhaps this is not interresting anymore because of being outdated/updated already, if so please don't waste anymore time on this) which let me to believe that /libndsfpc/nds/nds.inc requires 3 input.inc files:
1)a generic input.inc for both arm7 and arm9 targets
at /libndsfpc/nds/input.inc (this file was missing so did it myself)
2)an arm7 specific one at: /libndsfpc/nds/arm7/input.inc
3)an arm9 specific one at: /libndsfpc/nds/arm7/input.inc

BTW: I see were I did go wrong now, I was assuming to favourable (for me that is) on your statement "The svn trunk is compatible with r28". You meant the whole trunk whilst I was assuming only your project :) *shame on me*.
(were o were did I put those binoculars)

Sorry for the lenghty post and good luck with your updates. *thumbs up*