Notices

Ah sorry, here: http://people.bath.ac.uk/enpsgp/nokia770/OE_feed/vfp/

May be old now though.

Also note that the deps are wrong and may screw up your installing/uninstalling other things. Sorry.

Ah, bleeding edge stuff, eh? Yah, I think I'll hold back on trying out your Octave 3.0 builds unless you actually have a decently running build with real advantages over 2.9. Right now I just want to get 2.9 up and running to allow me to convert some basic Matlab scripts to run on my N800 (OS2008).

You say that your dep of libg2c may be old. Are you not playing with Octave anymore, or have you compiled a new version of libg2c for yourself? I'm curious as to what patching you had to do.

- Jim

Sort of, I don't think there's anything wrong with Octave 3.0, it's been released iirc. It should certainly run as well as 2.9 (afaik).

It ought to all be compatible with Chinook, but it's a bit old as I built it a while back (but as the GCC version hasn't changed that should be fine).

No, I've been busy DSP hacking, so haven't been using it. The same version of g2c should work for 2.9 I think. The feed I gave the url to was built using OpenEmbedded + Bitbake, it has some minor dep problems (naming differences) which might cause issues, otherwise it's fine.

Octave requires no tweaks/patches to build, the only thing that was done for the build in the feed was to add the -mcpu and -mfpu flags to enable hw floating point and any cpu optimisations that GCC might know of.

Someone should really submit a debian source package to Extras (I may do when I have some spare time)

Well, I took a stab at 3.0, but it was a mess and I still didn't have the shared libraries recognized in the end. I had to use dpkg -i --force-depend-version to get around the change in the version name for libstdc++ on most packages. Anyhow, I finally ended up clearing the mess and installing octave 2.9. Works great! Thanks!

- Jim

Bah...I must be missing something really simple. I've compiled and installed octave a couple times, but I'm still getting the dreaded floating point error on load. I configured with the following flags in scratchbox:
./configure CFLAGS="-O3 -mcpu=arm1136j-s -mtune=arm1136j-s -fomit-frame-pointer -mfpu=vfp" OPT_FLAGS = "-O3 -fomit-frame-pointer -mcpu=arm1136j-s -mfpu=vfp"

While compiling, I see that the "-mfpu" is getting used by gcc. This is compiling octave 3.0.1. What exactly where your flags when you configured?

- jim

Have you tried replacing:
-mcpu=arm1136j-s -mtune=arm1136j-s

with:
-mcpu=arm1136jf-s -mtune=arm1136jf-s

IIRC, the f specifies that the processor has a floating point. I also specify -mfloat-abi=softfp too.

Actually, try this:
CFLAGS="-O3 -fomit-frame-pointer -mcpu=arm1136jf-s -mtune=arm1136jf-s -mfpu=vfp -mfloat-abi=softfp" OPT_FLAGS = "-O3 -fomit-frame-pointer -mcpu=arm1136jf-s -mtune=arm1136jf-s -mfpu=vfp -mfloat-abi=softfp" ./configure

The lack of this may be the problem, the floating point error is caused as Octave looks at the floating point format to check the endianness of the processor, it may fall back to some strange format without this flag (e.g. the fpa one).

Crimony, how many flags does it take for this thing to figure out how to arrange the bytes? Anyhow, I'll give those flags a try tonight. I'm trying to nail this down so that gnuplot integration works (messed up endians means messed up stream-data to gnuplot).

Thanks!

- Jim

Please, who is going to upload octave/gnuplot to the extras repository? :P

I don't have the debian experience to upload to Extras. I'm just a simple Matlab programmer who does some basic C and Fortran code for numerical analysis. I don't know how to package this as a debian and I don't know how to bundle it to pass the "compile from source" requirement in the Extras repository. I'm cheating by using one of the VMWare Fusion disk images of Scratchbox, compiling within the Armel environment, and then copying all of the resulting files to their respective location on the N800. Yah...an ugly way to do things.

- Jim