devkitPro

neglectoru wrote: I'll try the binary distribution on both platforms, but then, I suppose, I need to compile libgba and libnds by hand (since the binary distributions don't come with these packages, right?)

Not necessarily, you can grab the binary tarballs of those packages as well, see http://wiki.devkitpro.org/index.php/Getting_Started for the links.

I tried building with various configurations of software

make 3.80 (which I built myself) or make 3.81 (ubuntu default)
gcc 4.2.3 (ubuntu default) or gcc 4.3 (which I built myself)

in all four configurations, it died in the same place.

That's really quite disturbing, the buildscripts work fine for me on all platforms I have access to, including Ubuntu. Do you have a previous version of devkitARM in the path when you're doing this? If you have then remove it from the path or delete/rename the devkitARM folder.

WinterMute wrote:

neglectoru wrote: I'll try the binary distribution on both platforms, but then, I suppose, I need to compile libgba and libnds by hand (since the binary distributions don't come with these packages, right?)

Not necessarily, you can grab the binary tarballs of those packages as well, see http://wiki.devkitpro.org/index.php/Getting_Started for the links.

I tried building with various configurations of software

make 3.80 (which I built myself) or make 3.81 (ubuntu default)
gcc 4.2.3 (ubuntu default) or gcc 4.3 (which I built myself)

in all four configurations, it died in the same place.

That's really quite disturbing, the buildscripts work fine for me on all platforms I have access to, including Ubuntu. Do you have a previous version of devkitARM in the path when you're doing this? If you have then remove it from the path or delete/rename the devkitARM folder.

I'm seeing similar issues. I'm also getting other errors after I pass the newlib point.

Which version of Ubuntu are you using? I'll make a virtual machine with it and try it if you tell me that.

I'm using the buildscripts which are on the download page of Sourceforge. If those aren't the right ones (I tired the CVS ones but they have a wrong version on one of the downloads), *please* let us know.

Ubuntu 8.04 for amd64
Debian 4.0 for the 32bit builds

The old make 3.81 problem was resolved by newlib 1.16.0

I really did nothing special for either system, I just followed my own directions in the readme supplied with the buildscripts & a toolchain popped out the other end. The last buildscripts release tarball was generated directly from the tree where devkitARM r23b was built.

Well, I have verified that clean installs of both Ubuntu 8.04 32-bit and Ubuntu 7.10 32-bit fail due to the INITFINI problem. I am currently uploading the VMWare images to my main server. If anybody *really* wants them, PM me and I will give you the links and the passwords. Be forewarned, these are 4-5 *GIGABYTE* images. It will take a while to download them, and you really need something which can resume on interrupt. You also need something which can play a VMWare image (the free VMWare Player should work but I have not tried).

I will try Ubuntu 8.04 64-bit and Debian 4.0 in 32-bit to see if it makes a difference. I'm downloading the Ubuntu 8.04 64-bit desktop CD right now, and I will do a netinstall for Debian 4.0r3-i386 32-bit to see what happens.

Edit: Debian 4.0r3 also confirmed broken. Same problem.

Edit: Even if I patch out the INITFINI problem, I get another one:

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

Same with me. I tried debian etch (4.0) and got the same problem:
#error why am I not defined

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.

This thread may or may not contain some hints - http://forums.devkitpro.org/viewtopic.php?f=2&t=61

bsder wrote: Edit: Even if I patch out the INITFINI problem, I get another one:

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

All bets are off if you do stupid things like that. The scripts work, the problem is related to how you're using them.

There is definitely something different about the setup of your machine. I wish I knew what it is, but whatever it is, it isn't a standard part of the debian installation. To test, I installed a new fresh copy of Debian 4.0 32 bit (using VMWare), and encountered problems.

Here is *exactly* what I did:

1. Install Debian etch into vmware. I did a basic installation, and didn't change any of the defaults.

2. Logged into my new debian system and installed sudo and bzip2
% apt-get install sudo bzip2

3. Installed the necessary build packages, as specified in the README
% sudo apt-get install build-essential autoconf automake bison flex libncurses5-dev libreadline-dev texinfo

4. I then installed gmp (4.2.1), which I need to build MPFR:
% sudo apt-get install libgmp3-dev

5. I downloaded MPFR and built it from source:
% wget http://www.mpfr.org/mpfr-current/mpfr-2.3.1.tar.bz2
% tar xvf mpfr-2.3.1.tar.bz2
% cd mpfr-2.3.1
% ./configure
% make
% sudo make install

6. Download the build scripts
% wget http://downloads.sourceforge.net/devkit ... 16.tar.bz2
% tar xvf buildscripts-20080516.tar.bz2
% cd buildscripts
% ./build-devkit.sh

When I ran the build scripts, I got the error I've described so many times.

I just registered to say that I'm having the same problem at HAVE_INITFINI_ARRAY ( I'm on a Mac OSX 10.4.11 ). I've tried gcc, gcc4.3 , make 3.79 3.8 and 3.81 ...

Then i tried to define it by hand ( with #define HAVE_INITFINI_ARRAY , before the evil #ifdef ). Then it compiled 'til the shl_load part, where it failed.

Googling around, i found a japanese (google-translated to english) blog, saying that this problem is caused by libtool.mp4; edited it, and deleted "configure".

Running the buildscript again, this time the error is at building the nds library. This is the error now:
As i can see, fooling the source by #defining HAVE_INITFINI_ARRAY wasn't enough; whatever "initfini" is, it is needed here (the error says ".init_array" and ".fini_array").

As I don't have even a clue about what those init/fini array things are... Is there some dependence I'm missing, that should provide them ? (so I wouldn't even need to fake that #define)

update: oops, the error message isn't complete... but there was a lot of errors about assembly-like sessions, like ".init_array" and ".fini_array"...

Meanwhile, is there a binary package of devkitARM that runs on Tiger (aka Mac OSX 10.4) ?

My first try was to download the package for mac, but it doesn't work - as it requires diferent versions of libraries, I guess it is Leopard-only...

My investigation seems to point to something similar.

binutils 2.18.50 builds without errors, but I think on my machine (and on others who have experienced problems) the built version is broken, and causes newlib to fail when building devkitARM.

I don't want to patch m4 files by hand, but I am curious what is different about WinterMute's setup which causes binutils to build properly. A different version of libtool, autoconf, or automake, perhaps?

Or, is there a different version of binutils that I could try?