devkitPro

WinterMute wrote:Then there's some problem with how you set up the prerequisites, the scripts work fine for me on pretty much every system I've tried them on. There's not really a lot I can do about this unfortunately, I'm at a loss to even come up with a question that might help diagnose your issue.

I presume that's true, but you're doing *something* different from the rest of us given that none of us seem to be able to make it compile on *any* distribution. If someone other than you has managed to compile it, I'd love to have them speak up so that we can compare.

While I can't outright identify the problem, I can do something to help put us all on the same page. I carved out a virtual machine on my colocated server and installed a completely clean version of Debian 4.0r3 on it just like you say you used for compilation.

If you send me a public key, I can give you an ssh login for directly on the virtual machine (I'll put the root password in your login directory). At that point, you can login, type "script" to capture all the output, and then proceed to run the buildscripts. I have *not* installed expat, mpfr, or gmp in case the method of installing those or the version numbers are the problem. Nor have I pulled the scripts in case those are the problem.

This way, we ought to be able to find out what the step is that we're all missing.

The buildscripts-20080602 is free of the INITFINI problem; i still needed to edit gcc's libtool.m4 , at line 5123, from to
(oops, almost forgot: i had to change the build-gcc.sh, to add: -with-gmp=/opt/local -with-mpfr=/opt/local , but it was just because they weren't on a default place)

I hope everything works now (compilation didn't ended yet, but it went through those earlier problems, and it's 3am here, I gotta sleep), otherwise i'll have to deal with devkitarm r20 (binary package for macosx 10.4)

update: forget what i said; when trying to compile an example (from the nds-examples), it still gives a initfini related error:

http://pastebin.com/m431ac4a2 (i've put the output on pastebin - the last time i tried to paste this, the forum truncated the output)

Well, it looks like it's r20 for me... (also, i really should go sleep)

second-update: This is weird: under $DEVKITPRO/examples/Graphics/3D/nehe/ , lesson01 to lesson03 compiles ok; but lesson04 gives that same linking error; half of the examples compiles, half doesn't.

I actually sat down and pulled newlib-1.16.0 and compiled it directly and it doesn't seem to have an INITFINI problem. This doesn't mean that it is functional, but it points a strong finger that something is wrong with the devkitarm code rather than newlib itself.

The fact that nobody else seems to be having INITFINI problems also points a finger at the devkitarm stuff.

I'm going to have a strong look at the newlib patches. The code patches are fairly obvious, but the automake/makefile patches aren't quite so straightforward. I especially don't like all the fiddling with dependencies as the last time INITFINI was an issue it seems like it was a dependency tree problem.

What about this error :

checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/home/andrewl/dkp/buildscripts/arm-eabi/gcc'
make: *** [all] Error 2

It's still present into last buildscripts version.
Does someone has an idea ?

volkmar wrote:What about this error :

checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/home/andrewl/dkp/buildscripts/arm-eabi/gcc'
make: *** [all] Error 2

It's still present into last buildscripts version.
Does someone has an idea ?

Yes, it's something in gcc or binutils. If you force the versions backward to the same ones used in the buildscripts-20080308, things seem to compile.

However, as a word of caution, there are some stray "^M" characters sitting toward the bottom of the build-devkit.sh file. It looks like this script didn't get tested on a *nix at all.

I can verify that I have managed a clean compile with newlib-1.16 and gmake 3.81 on one system. Once I isolate whether it is binutils or gcc causing the shl_load error, I'll try this out on a CentOS system as well as Debian to make sure this all works.

It should be noted that changing the versions in the buildscripts is highly inadvisable.

For what it's worth I've made some notes relating to the OSX version I built recently.

One of the biggest issues with building toolchain binaries is the need to minimise the extra dependencies the end user will need to install. With gcc 4.3.0 this means building static versions of gmp & mpfr rather than using fink or macports - either of the latter options introduces serious problems with the build due to linking against libraries which will not be installed on a normal user's machine. These extra dependencies are not fetched and built by the buildscripts because they are one shot installs. Once they are in place they do not need to be reinstalled.

Some users have reported problems if a previous version of devkitARM is in the path or in the target folder when building. It's worth deleting the installed devkitARM folder before proceeding with the buildscripts - this is something I've got into the habit of doing when rolling releases.

Firstly, Freeimage is needed to compile grit. All I did for this was download the 3.10.0 source distribution from http://freeimage.sourceforge.net/download.html, extract it & run make && sudo make install. I had to adjust the osx makefile for the ppc SDK installed on the machine.

For gmp I downloaded their source tarball from http://gmplib.org/#DOWNLOAD, extracted it and used configure . Adjusting the build manually is necessary to avoid some problems with assembly files in gmp, this information came from http://gmplib.org/macos.html. Note: I used --build here and not --host, the latter is used for cross compiling which isn't necessary and emits a scary warning. Once that's done a simple make && sudo make install does the rest. It's worth running make check to ensure all the tests are passed at this point. Obviously the build option should not be used on a linux system.

For mpfr it's the same procedure without the manual build system tweaking. http://www.mpfr.org/mpfr-current/#download for download, extract and configure
again, it's worth running make check here too.

Once the dependencies are installed then the buildscripts should just do their thing & pop out a nice shiny devkitARM at the other end.

In case anyone else is still having trouble with this, bsder has reported success with the most recent binutils snapshot. If things are still breaking for you then delete your binutils archive and grab the latest one.

There's also a known good snapshot @ http://sourceforge.net/project/showfile ... _id=517284

It appears that some version of the binutils snapshot has been the source of these errors. I have no idea which one unfortunately.

WinterMute wrote:There's also a known good snapshot @ http://sourceforge.net/project/showfile ... _id=517284

Bingo! This new version of binutils fixed the problems I was having compiling on all platforms. Everything is working for me now, even with the newer versions of the buildscripts.

Thanks!

Also working for me with binutils from devkitpro sourceforge page.

Thanks