devkitPro

When trying to compile devkitARM for windows I came across this issue:
http://sourceware.org/ml/binutils/2012-10/msg00044.html

The patch wasn't included in binutils 2.23.1 yet. I guess it's my fault for using the git version of the build scripts but I wanted to toy with gcc 4.7.2 to add some D (dlang.org) support.
Anyway, the solution is to either backport the patch to binutils 2.23.1 or to build binutils with --disable-plugins.

A new patch for binutils 2.23.1 and devkitARM is here: https://gist.github.com/jpf91/5089734

I also hit this problem when building devkitPPC for windows:
http://crosstool-ng.org/hg/crosstool-ng ... 2245834071
(the patch is for glibc but newlib has the same problem)

Has anyone seen this before?

Thanks for the binutils patch, much appreciated. I've been using a temporary bodge by creating an empty libdl.a to link against for windows targets until I had time to go digging a bit more. Many thanks for saving me the trouble

IIRC the issue with caddr_t is due to the use of macros in windows headers which confuse the compiler. I have a vague memory of having patched for that at some point but it may have only been done in the devkitARM patches. I'll dig around & see if I can find my notes for that.

I really wouldn't bother with D - supposedly there will be support for that added to mainstream gcc soon but currently it's a real mess and involves far too much work to be worth trying to maintain.

WinterMute wrote:I really wouldn't bother with D - supposedly there will be support for that added to mainstream gcc soon but currently it's a real mess and involves far too much work to be worth trying to maintain.

jpf is one of the GDC devs. If he's keen to make it work, I'd say he's qualified to do so
There are a few of us who would really like D in the toolchains. I've been trying to build it in there myself before, but I seem to suck at building GCC.
I'd personally like to have D working in all your toolchains so I can work on the runtimes for these platforms...

Well, being honest I don't envisage being able to accept patches that involve enabling D until it goes into upstream gcc because of the level of work needed to maintain it with our tools. I'm not that clear on why people are interested in using D on the DS either - is it really that suited to embedded dev? How much work is needed to allow use of libnds and friends with D and who's going to do that work?

I have to also confess to just not getting D but I'm an old school assembly programmer at heart and many of the languages some people want to see available for the DS offend me a bit. C/C++ and even objective C I get although I'm not keen on building toolsets that require more than vanilla C to use.

WinterMute wrote: I don't envisage being able to accept patches that involve enabling D until it goes into upstream gcc because of the level of work needed to maintain it with our tools.

That's understandable. D on embedded systems is far from ready and it's more likely that D is merged into GCC (not before gcc 4.9 though) before we actually have some DS support. I don't really want to see D support in official devkitARM releases, what I meant was I need to add D support in my personal devkitARM builds so we can start testing the compiler.

WinterMute wrote: is it really that suited to embedded dev

Of course that's also always a personal taste thing. There are some features in D that are certainly not usable in embedded dev (GC, TypeInfo but for lower level stuff even Classes, Exceptions might be overkill). On the other hand side D can be used as a more modern C-like subset with a proper module system, proper syntax for arrays, better strings, a safeD subset, sane syntax for function pointers, delegates, function overloading, CTFE (compile time function evaluation), templates (to a certain extent, think of binary bloat). See also: http://dlang.org/comparison.html (but beware that half of that list isn't valid for embedded...)

WinterMute wrote: How much work is needed to allow use of libnds and friends with D and who's going to do that work?

That's the easy part D can easily interface to C libraries. There are of course no changes to the C lib required. The headers need to be rewritten into D syntax, but as D is very C like that's usually a simple search&replace and we also have some advanced tools to do that translation. Macros have to be translated manually, so here some work is involved, but that's it. Adapting the standard library to support threading and similar OS stuff might be more difficult, but for a simple start we don't need the standard library.

The bigger problem is that D is currently mainly used on x86/x86_64 and desktop computers. The runtime needs to be adapted for embedded needs (or maybe a new runtime should be written) and the compiler should avoid inserting some library calls. For now I'm mainly interested in getting D (better: the Gnu D compiler) work on ARM at all. Then making it work on the DS would be a nice side project.

I finally got around to looking into these issues and update the upstream sources we're using.

devkitARM release 42 is almost ready to go, I just have a bit more testing to do with gcc 4.8.1 and fix a few new warnings when compiling DS libraries. All the tool related changes are now in the git buildscripts on the master branch although you'll probably need to grab git versions of various libraries to get it to build. I've included the binutils patch you found for the libdl.a issue too.

For devkitPPC release 27 I've created a new devkitPPC_r27 branch. I'm updating to binutils 2.23.1, gcc-4.8..1, newlib-2.0.0 and gdb 7.6.1. Again I've added the binutils patch you found but I haven't got any further than making sure the new toolchain actually builds existing wii/gamecube examples without problems. Whether or not the binaries actually work on hardware remains to be seen The caddr_t issue is fixed anyway so hopefully that should help.