Compiling Natively on PDAXROM

[omega]

okay...  the fortran libraries are not in the fort77 directory, as i said - but octave seems to compile those parts without problems.

Can octave 2.1.59 take four - five hours more than 2.1.57?  

Regarding both, there is not octave binary created - hence the problem.

Clarify this please - make should compile everything, make install should just copy the stuff?  When i do make install (with other programs that work successfully, such as dosbox), some parts are compiled also by make install...

[lardman]

Make compiles the whole lot; make install probably strips the binaries.

Can octave 2.1.59 take four - five hours more than 2.1.57?

Not on my P4-1.4GHz, as the entire build process probably only takes 1 hour or so (at a guess); on a Z I've no idea.

Regarding both, there is not octave binary created - hence the problem.

If make finishes then there should be a binary somewhere. Probably in the source directory now that I think about it: octave-2.1.57\src

It will be rather large (as it's unstripped).


Simon

[omega]

When i was compiling 2.1.59 last night i told it to leave the debugging symbols out of it.  This morning it was stuff looping around the liboctave directory. It compiles it then leave and reenters it and starts compiling again.

I'm happy that i've got EVERY single other thing that i've compiling, some games, dosbox, gputils (pic dev stuff), xgpasm (x front end for previous), bison, fort77, flex. I even now have these installed on a mounted image sitting on a samba share (i will move this to my 1gig CF in the next few hours).

What advice can you give me about octave anyone? There is no octave binary sitting anywhere....   is there any libraries i should check for?

[omega]

Another question. If i terminate a make using Ctrl-C, and i type make again - is it expected to complete normally?

[omega]

I just found out that fort77 just calls f2c, so that f2c looks like a real compiler... How can i check that f2c is installed correctly, is there a f2c that will actually install itself? I had to copy three files myself, I may have needed the rest of them.... why no ./configure ; make ; make install source files available?

[lardman]

is there any libraries i should check for?

Probably also in /src do an 'ls -a', they should be in a /.libs directory.

I just found out that fort77 just calls f2c, so that f2c looks like a real compiler... How can i check that f2c is installed correctly, is there a f2c that will actually install itself? I had to copy three files myself, I may have needed the rest of them.... why no ./configure ; make ; make install source files available?

No idea, sorry.


Si

[Zumi]

This octave really doesn't want to be compiled.
I'm trying to cross-compile it but it seems that I will need to recompile my gcc with fortran support. I already edited the Makefiles at two places (where it wanted to use the programs it compiled before, but they were arm binaries so it wasn't able... they were only doc files however).
I ran into a problem:

Code: [Select]

make[2]: Entering directory `/opt/arm/src/octave-2.1.57/src'
making defaults.h from defaults.h.in
defaults.h is unchanged
making oct-conf.h from oct-conf.h.in
oct-conf.h is unchanged
g++  -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -DHAVE_CONFIG_H  -Wall -W -Wshadow -O  \
-L..  -fPIC  -o octave \
main.o  balance.o  besselj.o  betainc.o  chol.o  colloc.o  daspk.o  dasrt.o  dassl.o  det.o  eig.o  expm.o  fft.o  fft2.o  fftn.o  fftw_wisdom.o  filter.o  find.o  fsolve.o  gammainc.o  getgrent.o  getpwent.o  getrusage.o  givens.o  hess.o inv.o  kron.o  lpsolve.o  lsode.o  lu.o  minmax.o  odessa.o  pinv.o  qr.o  quad.o  qz.o  rand.o  schur.o  sort.o  sqrtm.o  svd.o  syl.o  time.o \
-L../liboctave -L../libcruft -L../src -Wl,-rpath -Wl,/usr/local/lib/octave-2.1.57 \
../src/liboctinterp.a ../liboctave/liboctave.a  ../libcruft/libcruft.a  ../glob/glob.o ../glob/fnmatch.o  \
   -lreadline  -lncurses -lm
../liboctave/liboctave.a(file-ops.o)(.text+0x2b18): In function `file_ops::tempnam(std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&, std::basic_string, std::allocator >&)':
: warning: the use of `tempnam' is dangerous, better use `mkstemp'
../src/liboctinterp.a(xerbla.o)(.text+0x10): In function `xerbla_':
: undefined reference to `s_wsfe'
../src/liboctinterp.a(xerbla.o)(.text+0x20): In function `xerbla_':
: undefined reference to `do_fio'
../src/liboctinterp.a(xerbla.o)(.text+0x30): In function `xerbla_':
: undefined reference to `do_fio'
../src/liboctinterp.a(xerbla.o)(.text+0x34): In function `xerbla_':
: undefined reference to `e_wsfe'
../libcruft/libcruft.a(zairy.o)(.text+0x1554): In function `zairy_':
/opt/arm/src/octave-2.1.57/libcruft/amos/zairy.c:347: undefined reference to `pow_dd'
../libcruft/libcruft.a(zbesh.o)(.text+0x710): In function `zbesh_':and a _lot_ of line like these follows 'till make halts.
I read topics on other forums about this and they say compiling with a fortran enabled gcc works. I hope it will... I want this app!

Zumi

[omega]

Well lardman should definitely be able to compile it, as he did before for cacko.  I'm running another compile now.....  Anyone want to recompile gcc with g77 support? ;-)

[omega]

last night i left it on to compile 2.1.61 this time and i ran out of space on /tmp?  It's a ramdisk???   Anyhow, i renamed that symlink and made a symlink from /tmp to /mnt/cf (microdrive) for now... Probably make it a lot slower?  Does it not dynamically resize (/dev/shm/tmp) if necessary?

[lardman]

I already edited the Makefiles at two places (where it wanted to use the programs it compiled before, but they were arm binaries so it wasn't able... they were only doc files however).

Rather than editing the Makefile you can just run the commands in another terminal (which hasn't sourced the shell script to make it use the cross-toolchain), then start Make again (in the original window) and it will continue where it left off.

Well lardman should definitely be able to compile it, as he did before for cacko. I'm running another compile now..... Anyone want to recompile gcc with g77 support? ;-)

I can, so can anyone who uses OE as it's in there now..... ;-)

I'm sure pdaXrom could start using OE as their build system... It's very good really :-)

I have downloaded the pdaXrom toolchain and if I have some spare time over the weekend I'll take a look at compiling F77 support and compiling octave; that said, I don't use pdaXrom, so this is really not very high on my list of priorities (which go something like: go out for a few beers, meet some pretty girls, sleep a bit, finish my PhD, compile Octave for pdaXrom users ;-), so chances are it won't actually happen for a while.

Zumi, I'd search for the location of the undefined references to see if you need another lib (header); I'd also ask the pdaXrom team to produce a toolchain with F77 built in to save the hassle.


Si

[omega]

Me again.

I haven't had time to try compiling again on the Zaurus since I last posted. Anyone else had any luck with Octave? I would try the cross-compiler but someone has already tried that.

Any sign of a G77 enable PDAXROM native toolchain?  How hard is it to recompile GCC from scratch with G77 enabled on my Zaurus?  I will need octave (with Gnuplot) for my oscilloscope project just after christmas so if i can't get it going i will have to go back to Cacko and use the octave that worked then - but i don't want to! :-(

Anyone else know a way to feed numbers from the serial port to gnuplot so i can graph a waveform?