OSX Version of R22 or R23 coming?

[tristero]

Is the OSX version of R23 going to be released? Failing that, are the sources going to be checked in so that I can have a go at getting it going myself?

From what I can see, the build scripts in cvs on sourceforge are for R21

Revision 1.101 - (download) (as text) (annotate)
Tue Apr 29 18:02:54 2008 UTC (39 hours, 49 minutes ago) by wntrmute
Branch: MAIN
CVS Tags: HEAD
Changes since 1.100: +2 -2 lines
include path for config.sh
1 #!/bin/sh
2 #---------------------------------------------------------------------------------
3 # Build scripts for
4 # devkitARM release 21
5 # devkitPPC release 14
6 # devkitPSP release 12

though the cvs checkin messages suggest they do R23?

Revision 1.99 - (view) (download) (as text) (annotate) - [select for diffs]
Sun Apr 27 03:42:37 2008 UTC (4 days, 6 hours ago) by wntrmute
Branch: MAIN
Changes since 1.98: +7 -5 lines
Diff to previous 1.98
devkitPPC r15 & devkitARM r23 updates

Perhaps the R23 script is checked in and its just the comment being wrong???

[WinterMute]

It's not currently possible to build devkitARM release 23 for OSX, it's being worked on.

The version numbers in the buildscripts will be updated when they're released, please be patient. Unfortunately there was a problem with the update to newlib and release 23a will arrive soon. Please be patient.

[tristero]

It's not currently possible to build devkitARM release 23 for OSX, it's being worked on.

Is this the fact that gmp isn't available, or something else?

(ie, should I waste my time trying to get it going myself and feedback if I'm successful?)

I can see that things like grit need a lot of libraries that aren't available by default, which is a pain.

[WinterMute]

It's the gmp & mpfr libraries along with something else we're in the process of resolving. The current CVS buildscripts aren't yet in a state where feedback would be helpful.

On the other hand if you're prepared to put in a bit more work than you'd normally need to build a toolchain for local use then I could do with some extra hands in the OSX department Drop by the IRC channels if you want to help out - #dsdev on Blitzed

[tristero]

On the other hand if you're prepared to put in a bit more work than you'd normally need to build a toolchain ...

I've gotten a mostly complete build through on Intel and its compiled three of my apps without any problems, though the fourth is behaviour oddly. My poor old eMac is slowly churning away at the PPC build and we'll see how well that works...

[WinterMute]

I have no idea what on earth any of you mac peeps are doing with these buildscripts

Last night I managed to get a shell on an OSX 10.5.2 box and I built devkitARM after about half an hour fiddling about with dependencies. I had none of the issues that have been reported so I'm not sure how to advise anyone how to go about building things.

In the meantime here's a test build of release 23a for intel OSX.

http://www.davejmurphy.com/devkitARM_r2 ... el.tar.bz2

Let me know how that works out for you.

[tristero]

I have no idea what on earth any of you mac peeps are doing with these buildscripts

Well, given that the FSF themselves admit that gcc4.3.0 has problems building newlib for "machines that are close to the metal", I'm somewhat surprised that you don't get the problems yourself. The default behaviour of the standard gcc configure scripts is to do "shared library support" but for some reason, configure thinks it actually needs to *run test programs* to determine whether certain features are present. Clearly, that can't work in a cross-compiler environment, but its what the latest sanctioned release does.

Added --disable-shared to the configure command for newlib let me run the complete build on Intel, and has gotten 90% through, though barfed on some of the libmirko stuff, on PPC.

I'll take a look at your 23a binaries and see how it all hangs together. But so far I haven't encountered any of the other problems you alluded to - then again, I'm only compiling Woopsi-derived programs, nothing that goes too close to the metal, sprites, 3d, sound, etc...

[WinterMute]

Well, given that the FSF themselves admit that gcc4.3.0 has problems building newlib for "machines that are close to the metal", I'm somewhat surprised that you don't get the problems yourself. The default behaviour of the standard gcc configure scripts is to do "shared library support" but for some reason, configure thinks it actually needs to *run test programs* to determine whether certain features are present. Clearly, that can't work in a cross-compiler environment, but its what the latest sanctioned release does.

Yet clearly it can, and in fact does, work. As it happens I implemented one of the workarounds for this problem some time ago in order to make configuring of 3rd party libraries work without hacking around with extra parameters for linking.

Added --disable-shared to the configure command for newlib let me run the complete build on Intel, and has gotten 90% through, though barfed on some of the libmirko stuff, on PPC.

Your need to do that indicates an issue with the rest of the build, as does the barfing on libmirko. Given that I've managed to build a working toolchain on OSX without altering the buildscripts I can't see why it would be necessary for anyone else to change anything.

I'll take a look at your 23a binaries and see how it all hangs together. But so far I haven't encountered any of the other problems you alluded to - then again, I'm only compiling Woopsi-derived programs, nothing that goes too close to the metal, sprites, 3d, sound, etc...

The newlib problems are related to parts of the stdio library which you won't encounter unless you're working with file IO and some time related functions.

[tristero]

I have no idea what on earth any of you mac peeps are doing with these buildscripts

Well, given that the FSF themselves admit that gcc4.3.0 has problems building newlib for "machines that are close to the metal", I'm somewhat surprised that you don't get the problems yourself.

Apparently I was mistaken - thats the last time I trust what I read on the Internet.

At your advice, I started again from scratch, grabbed the latest cvs checkins and built the whole thing from scratch, and it went through without problems (on Intel - haven't done PPC yet). I can only assume that I had *still* had partial builds in my system somehow previously (perhaps after I got the first problem, and went to get gmp/mpfr).

There are still niggling things being reported which are obviously problems:

strip: can't process non-object and non-archive file: /projects/dkp23/devkitARM/bin/arm-eabi-gccbug
strip: can't map file: /projects/dkp23/devkitARM/libexec/gcc/arm-eabi/4.3.0/install-tools (Invalid argument)

the first one is a shellscript, the second a directory. Anything that tries to run strip on them is making a mistake. Since the script contains:

for f in $INSTALLDIR/$package/bin/* \
$INSTALLDIR/$package/$target/bin/* \
$INSTALLDIR/$package/libexec/gcc/$target/$GCC_VER/*
do
strip $f
done

its no surprise. And getting to that point means that all the other builds worked fine.

[tristero]

At your advice, I started again from scratch, grabbed the latest cvs checkins and built the whole thing from scratch, and it went through without problems (on Intel - haven't done PPC yet). I can only assume that I had *still* had partial builds in my system somehow previously (perhaps after I got the first problem, and went to get gmp/mpfr).

Ok, I have to say, all bets are off. I just did the PPC build (from scratch) and it barfed somewhere different. it actually complained about 'bad assembler option "r"' which is just insane. After a few more attempts (which all died at the same place) I decided to restart the terminal process just to see if some process limit had been hit.

Bingo.

Started a new terminal, restarted the build process and it got past the sticking point and kept on rocking.

Now, why that might happen, I have no idea. But thats my new symptom, and I'm prepared to call that a system glitch of some form, perhaps running out of file handles, or temporary disk space. Or perhaps its Spotlight stepping in and trying to index the temp files as it goes. That'd suck. But its not something thats ever going to be deterministic, nor is it the fault of the package being built. And Spotlight, or Time Machine, stepping in and messing with stuff (ie, preventing temporary build files from being deleted) might even explain why my previous download+build was so hit and miss.