Octave 3.1.51 available for ftp

[John W. Eaton]

A new snapshot of Octave is now available for ftp from ftp.octave.org in the
directory /pub/octave/bleeding-edge:

  389be5a9f130f369d598795bc97100a9  octave-3.1.51.tar.bz2
  4d339148860fe12fc27fa4b5a32c6d21  octave-3.1.51.tar.gz
  5470c0ef59bfa74bb84fc678709cdb1e  octave-3.1.50-3.1.51.patch.bz2
  f95947a49ebf8344f3d9bf31d6acfc6f  octave-3.1.50-3.1.51.patch.gz

  -rw-r--r-- 1 506 1012 10709063 Jul 22 15:26 octave-3.1.51.tar.bz2
  -rw-r--r-- 1 506 1012 12282601 Jul 22 15:28 octave-3.1.51.tar.gz
  -rw-r--r-- 1 506 1012    29803 Jul 22 15:28 octave-3.1.50-3.1.51.patch.bz2
  -rw-r--r-- 1 506 1012    32515 Jul 22 15:28 octave-3.1.50-3.1.51.patch.gz

The snapshot is tagged in the usual way (ss-3-1-51) in the Mercurial
archive and will be marked as the "development" version of
Octave on the download page of the Octave web site.

A number of configuration problems that appeared in the previous
snapshot have been fixed.

Please remember that these snapshots are provided for testing
purposes.  I do not consider them to be Octave releases.  If people
think there will be confusion because of the version number, then we
can add a notice to the Octave startup message.  Changing the version
number to something like ss-2008-07-21 is not an option because it
will cause trouble with typical version comparison functions (for
example, that are sometimes used for building Octave Forge packages).

This snapshot includes the new experimental OpenGL-based graphics
code, but the gnuplot backend is used by default.  Assuming you have
all the required libraries and have built the OpenGL bits properly,
you should be able to switch to the new backend with the commands

  input_event_hook ("__fltk_redraw__");
  __init_fltk__ ();
  set (0, "defaultfigure__backend__", "fltk");

I'm sure there will be a simpler way to do this once the new backend
code is more mature.

jwe

[Thomas Treichl]

John W. Eaton schrieb:

> A number of configuration problems that appeared in the previous
> snapshot have been fixed.
>
> Please remember that these snapshots are provided for testing
> purposes.  I do not consider them to be Octave releases.  If people
> think there will be confusion because of the version number, then we
> can add a notice to the Octave startup message.  Changing the version
> number to something like ss-2008-07-21 is not an option because it
> will cause trouble with typical version comparison functions (for
> example, that are sometimes used for building Octave Forge packages).

Hi John,

thanks for that snapshot tarball. As you mentioned before 3.1.50 did not
configure well, dito on MacOSX, that's why I was not successful compiling the
3.1.50 sources and did not report back. 3.1.51 is much better and it compiles in
the usual fine way.

There is one thing that I still don't understand when I compile the sources and
maybe someone can give me a hand here: If I try to link liboctave then I get the
following error (I know this since building 2.9.12 but I always thought that
this may be a special problem of my machine?!):

   ld: Undefined symbols:
   _fftw_destroy_plan referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3.3.dylib
   _fftw_execute_dft referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3.3.dylib
   _fftw_execute_dft_r2c referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3.3.dylib
   _fftw_import_system_wisdom referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3.3.dylib
   _fftw_plan_many_dft referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3.3.dylib
   _fftw_plan_many_dft_r2c referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3.3.dylib
   _fftwf_destroy_plan referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3f.3.dylib
   _fftwf_execute_dft referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3f.3.dylib
   _fftwf_execute_dft_r2c referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3f.3.dylib
   _fftwf_import_system_wisdom referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3f.3.dylib
   _fftwf_plan_many_dft referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3f.3.dylib
   _fftwf_plan_many_dft_r2c referenced from liboctave expected to be defined in
   /tmp/dependencies-i386/lib/libfftw3f.3.dylib
   /usr/bin/libtool: internal link edit command failed
   make[2]: *** [liboctinterp.dylib] Error 1
   make[1]: *** [src] Error 2
   make: *** [all] Error 2
   solvedeps-3.1.51.sh: Building Octave.app has failed !!

My workaround for this is to apply a patch of the following form:

   --- octave-3.1.51.orig/src/Makefile.in
   +++ octave-3.1.51/src/Makefile.in

    OCTINTERP_LINK_DEPS = \
      -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $(FLIBS) \
   -  $(OPENGL_LIBS)
   +  $(OPENGL_LIBS) $(FFTW_LIBS)

    OCT_LINK_DEPS = \
      -L../libcruft $(LIBCRUFT) -L../liboctave $(LIBOCTAVE) \

then I can link liboctave.dylib without any problems left. Any ideas what may
cause the above problem?

Now that I have another 3.1.51 i386 MacOSX Octave.app binary version should I
make that available for download via SourceForge? I also have to say that it is
not a clean build. I've taken the external libs and startup scripts from 3.0.1
Octave.app, extended these by FLTK, FTGL, GraphicsMagick++ and others and packed
that again (there may still exist dependency problems on other machines)... I
don't plan to make a PPC 3.1.51 but must check if 3.1.51 can be build against
SDK 10.3.9 PPC which I think could become hard or impossible. If this is true
then 3.1.xx PPC will only be available for OSX 10.4 or higher and Octave.app
3.0.x will be the last release which can be run on PPC 10.3.9...

Regards,

   Thomas

[Rafael Laboissiere]

* John W. Eaton <jwe@...> [2008-07-22 11:39]:

> A new snapshot of Octave is now available for ftp from ftp.octave.org in the
> directory /pub/octave/bleeding-edge:
> [snip]

Debian packages for 3.1.51 have been uploaded to experimental [1] and are
also available from my apt-getable repository [2], as usual.
 
[1] http://ftp-master.debian.org/new/octave3.1_3.1.51-1.html
[2] http://people.debian.org/~rafael/octave3.1/

--
Rafael

[John W. Eaton]

On 23-Jul-2008, Thomas Treichl wrote:

| There is one thing that I still don't understand when I compile the sources and
| maybe someone can give me a hand here: If I try to link liboctave then I get the
| following error (I know this since building 2.9.12 but I always thought that
| this may be a special problem of my machine?!):
|
|    ld: Undefined symbols:
|    _fftw_destroy_plan referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3.3.dylib
|    _fftw_execute_dft referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3.3.dylib
|    _fftw_execute_dft_r2c referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3.3.dylib
|    _fftw_import_system_wisdom referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3.3.dylib
|    _fftw_plan_many_dft referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3.3.dylib
|    _fftw_plan_many_dft_r2c referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3.3.dylib
|    _fftwf_destroy_plan referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3f.3.dylib
|    _fftwf_execute_dft referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3f.3.dylib
|    _fftwf_execute_dft_r2c referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3f.3.dylib
|    _fftwf_import_system_wisdom referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3f.3.dylib
|    _fftwf_plan_many_dft referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3f.3.dylib
|    _fftwf_plan_many_dft_r2c referenced from liboctave expected to be defined in
|    /tmp/dependencies-i386/lib/libfftw3f.3.dylib
|    /usr/bin/libtool: internal link edit command failed
|    make[2]: *** [liboctinterp.dylib] Error 1
|    make[1]: *** [src] Error 2
|    make: *** [all] Error 2
|    solvedeps-3.1.51.sh: Building Octave.app has failed !!
|
| My workaround for this is to apply a patch of the following form:
|
|    --- octave-3.1.51.orig/src/Makefile.in
|    +++ octave-3.1.51/src/Makefile.in
|
|     OCTINTERP_LINK_DEPS = \
|       -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $(FLIBS) \
|    -  $(OPENGL_LIBS)
|    +  $(OPENGL_LIBS) $(FFTW_LIBS)
|
|     OCT_LINK_DEPS = \
|       -L../libcruft $(LIBCRUFT) -L../liboctave $(LIBOCTAVE) \
|
| then I can link liboctave.dylib without any problems left. Any ideas what may
| cause the above problem?

As far as I can tell, fftw functions are only referenced directly in
liboctave, so I don't see why you should need to also link the fftw
library directly with liboctinterp.  If this is needed for fftw, why
is it not also needed for the suitesparse libraries?

jwe

[dbateman]

John W. Eaton wrote:

As far as I can tell, fftw functions are only referenced directly in
liboctave, so I don't see why you should need to also link the fftw
library directly with liboctinterp.  If this is needed for fftw, why
is it not also needed for the suitesparse libraries?

Maybe the  Ffftw function is the cause of this. I can't remember whether this was made matlab compatible before or after 3.0.0, but if after, then this would explain the link issue.

D.

[Thomas Treichl]

dbateman schrieb:
> John W. Eaton wrote:
>> As far as I can tell, fftw functions are only referenced directly in
>> liboctave, so I don't see why you should need to also link the fftw
>> library directly with liboctinterp.  If this is needed for fftw, why
>> is it not also needed for the suitesparse libraries?
>
> Maybe the  Ffftw function is the cause of this. I can't remember whether
> this was made matlab compatible before or after 3.0.0, but if after, then
> this would explain the link issue.

Hallo again,

I'm very slow, but I once again had a look at this problem. The functions that
are not found when linking liboctinterp.dylib can be found each at the end of
the following outputs.
For suitesparse I'm using static *.a libraries only because I don't know how to
build shared ones on MacOSX. For fftw I'm building shared *.dylib libraries only
which is easy to do. Can this be the origin of this problem?

   Thomas


~/Development/octave $ nm liboctave/pic/oct-fftw.o | grep _fftw
00027250 s __GLOBAL__I__ZN19octave_fftw_plannerC2Ev
00000000 a __GLOBAL__I__ZN19octave_fftw_plannerC2Ev.eh
00003b70 T __ZN11octave_fftw3fftEPKSt7complexIdEPS1_mmii
000275d4 S __ZN11octave_fftw3fftEPKSt7complexIdEPS1_mmii.eh
00004de0 T __ZN11octave_fftw3fftEPKSt7complexIfEPS1_mmii
000276f4 S __ZN11octave_fftw3fftEPKSt7complexIfEPS1_mmii.eh
000038d0 T __ZN11octave_fftw3fftEPKdPSt7complexIdEmmii
000275a4 S __ZN11octave_fftw3fftEPKdPSt7complexIdEmmii.eh
00004b50 T __ZN11octave_fftw3fftEPKfPSt7complexIfEmmii
000276c4 S __ZN11octave_fftw3fftEPKfPSt7complexIfEmmii.eh
00003d00 T __ZN11octave_fftw4ifftEPKSt7complexIdEPS1_mmii
00027604 S __ZN11octave_fftw4ifftEPKSt7complexIdEPS1_mmii.eh
00004f70 T __ZN11octave_fftw4ifftEPKSt7complexIfEPS1_mmii
00027724 S __ZN11octave_fftw4ifftEPKSt7complexIfEPS1_mmii.eh
00004710 T __ZN11octave_fftw5fftNdEPKSt7complexIdEPS1_iRK10dim_vector
00027664 S __ZN11octave_fftw5fftNdEPKSt7complexIdEPS1_iRK10dim_vector.eh
000059c0 T __ZN11octave_fftw5fftNdEPKSt7complexIfEPS1_iRK10dim_vector
00027784 S __ZN11octave_fftw5fftNdEPKSt7complexIfEPS1_iRK10dim_vector.eh
00004000 T __ZN11octave_fftw5fftNdEPKdPSt7complexIdEiRK10dim_vector
00027634 S __ZN11octave_fftw5fftNdEPKdPSt7complexIdEiRK10dim_vector.eh
00005250 T __ZN11octave_fftw5fftNdEPKfPSt7complexIfEiRK10dim_vector
00027754 S __ZN11octave_fftw5fftNdEPKfPSt7complexIfEiRK10dim_vector.eh
00004880 T __ZN11octave_fftw6ifftNdEPKSt7complexIdEPS1_iRK10dim_vector
00027694 S __ZN11octave_fftw6ifftNdEPKSt7complexIdEPS1_iRK10dim_vector.eh
00005b30 T __ZN11octave_fftw6ifftNdEPKSt7complexIfEPS1_iRK10dim_vector
000277b4 S __ZN11octave_fftw6ifftNdEPKSt7complexIfEPS1_iRK10dim_vector.eh
00001180 T __ZN19octave_fftw_planner11create_planEi10dim_vectoriiiPKdPSt7complexIdE
00027430 S
__ZN19octave_fftw_planner11create_planEi10dim_vectoriiiPKdPSt7complexIdE.eh
00000960 T
__ZN19octave_fftw_planner11create_planEii10dim_vectoriiiPKSt7complexIdEPS2_
00027400 S
__ZN19octave_fftw_planner11create_planEii10dim_vectoriiiPKSt7complexIdEPS2_.eh
00000010 T __ZN19octave_fftw_planner6methodENS_10FftwMethodE
00027368 S __ZN19octave_fftw_planner6methodENS_10FftwMethodE.eh
00000000 T __ZN19octave_fftw_planner6methodEv
00000000 A __ZN19octave_fftw_planner6methodEv.eh
000026d0 T __ZN19octave_fftw_plannerC1Ev
000274c8 S __ZN19octave_fftw_plannerC1Ev.eh
000020d0 T __ZN19octave_fftw_plannerC2Ev
00027490 S __ZN19octave_fftw_plannerC2Ev.eh
00000140 T
__ZN25octave_float_fftw_planner11create_planEi10dim_vectoriiiPKfPSt7complexIfE
000273d0 S
__ZN25octave_float_fftw_planner11create_planEi10dim_vectoriiiPKfPSt7complexIfE.eh
000018c0 T
__ZN25octave_float_fftw_planner11create_planEii10dim_vectoriiiPKSt7complexIfEPS2_
00027460 S
__ZN25octave_float_fftw_planner11create_planEii10dim_vectoriiiPKSt7complexIfEPS2_.eh
000000a0 T __ZN25octave_float_fftw_planner6methodENS_10FftwMethodE
0002739c S __ZN25octave_float_fftw_planner6methodENS_10FftwMethodE.eh
00000090 T __ZN25octave_float_fftw_planner6methodEv
00000000 A __ZN25octave_float_fftw_planner6methodEv.eh
000032d0 T __ZN25octave_float_fftw_plannerC1Ev
00027538 S __ZN25octave_float_fftw_plannerC1Ev.eh
00002cd0 T __ZN25octave_float_fftw_plannerC2Ev
00027500 S __ZN25octave_float_fftw_plannerC2Ev.eh
          U _fftw_destroy_plan
          U _fftw_execute_dft
          U _fftw_execute_dft_r2c
          U _fftw_import_system_wisdom
          U _fftw_plan_many_dft
          U _fftw_plan_many_dft_r2c
000278e0 S _fftw_planner
          U _fftwf_destroy_plan
          U _fftwf_execute_dft
          U _fftwf_execute_dft_r2c
          U _fftwf_import_system_wisdom
          U _fftwf_plan_many_dft
          U _fftwf_plan_many_dft_r2c
00027880 S _float_fftw_planner
~/Development/octave $


~/Development/octave $ nm liboctave/liboctave.dylib | grep _fftw
00a4afb0 s __GLOBAL__I__ZN19octave_fftw_plannerC2Ev
00000000 a __GLOBAL__I__ZN19octave_fftw_plannerC2Ev.eh
000469f0 T __ZN11octave_fftw3fftEPKSt7complexIdEPS1_mmii
00a61b88 S __ZN11octave_fftw3fftEPKSt7complexIdEPS1_mmii.eh
00047c60 T __ZN11octave_fftw3fftEPKSt7complexIfEPS1_mmii
00a61ca8 S __ZN11octave_fftw3fftEPKSt7complexIfEPS1_mmii.eh
00046750 T __ZN11octave_fftw3fftEPKdPSt7complexIdEmmii
00a61b58 S __ZN11octave_fftw3fftEPKdPSt7complexIdEmmii.eh
000479d0 T __ZN11octave_fftw3fftEPKfPSt7complexIfEmmii
00a61c78 S __ZN11octave_fftw3fftEPKfPSt7complexIfEmmii.eh
00046b80 T __ZN11octave_fftw4ifftEPKSt7complexIdEPS1_mmii
00a61bb8 S __ZN11octave_fftw4ifftEPKSt7complexIdEPS1_mmii.eh
00047df0 T __ZN11octave_fftw4ifftEPKSt7complexIfEPS1_mmii
00a61cd8 S __ZN11octave_fftw4ifftEPKSt7complexIfEPS1_mmii.eh
00047590 T __ZN11octave_fftw5fftNdEPKSt7complexIdEPS1_iRK10dim_vector
00a61c18 S __ZN11octave_fftw5fftNdEPKSt7complexIdEPS1_iRK10dim_vector.eh
00048840 T __ZN11octave_fftw5fftNdEPKSt7complexIfEPS1_iRK10dim_vector
00a61d38 S __ZN11octave_fftw5fftNdEPKSt7complexIfEPS1_iRK10dim_vector.eh
00046e80 T __ZN11octave_fftw5fftNdEPKdPSt7complexIdEiRK10dim_vector
00a61be8 S __ZN11octave_fftw5fftNdEPKdPSt7complexIdEiRK10dim_vector.eh
000480d0 T __ZN11octave_fftw5fftNdEPKfPSt7complexIfEiRK10dim_vector
00a61d08 S __ZN11octave_fftw5fftNdEPKfPSt7complexIfEiRK10dim_vector.eh
00047700 T __ZN11octave_fftw6ifftNdEPKSt7complexIdEPS1_iRK10dim_vector
00a61c48 S __ZN11octave_fftw6ifftNdEPKSt7complexIdEPS1_iRK10dim_vector.eh
000489b0 T __ZN11octave_fftw6ifftNdEPKSt7complexIfEPS1_iRK10dim_vector
00a61d68 S __ZN11octave_fftw6ifftNdEPKSt7complexIfEPS1_iRK10dim_vector.eh
00044000 T __ZN19octave_fftw_planner11create_planEi10dim_vectoriiiPKdPSt7complexIdE
00a619e4 S
__ZN19octave_fftw_planner11create_planEi10dim_vectoriiiPKdPSt7complexIdE.eh
000437e0 T
__ZN19octave_fftw_planner11create_planEii10dim_vectoriiiPKSt7complexIdEPS2_
00a619b4 S
__ZN19octave_fftw_planner11create_planEii10dim_vectoriiiPKSt7complexIdEPS2_.eh
00042e90 T __ZN19octave_fftw_planner6methodENS_10FftwMethodE
00a6191c S __ZN19octave_fftw_planner6methodENS_10FftwMethodE.eh
00042e80 T __ZN19octave_fftw_planner6methodEv
00000000 A __ZN19octave_fftw_planner6methodEv.eh
00045550 T __ZN19octave_fftw_plannerC1Ev
00a61a7c S __ZN19octave_fftw_plannerC1Ev.eh
00044f50 T __ZN19octave_fftw_plannerC2Ev
00a61a44 S __ZN19octave_fftw_plannerC2Ev.eh
00042fc0 T
__ZN25octave_float_fftw_planner11create_planEi10dim_vectoriiiPKfPSt7complexIfE
00a61984 S
__ZN25octave_float_fftw_planner11create_planEi10dim_vectoriiiPKfPSt7complexIfE.eh
00044740 T
__ZN25octave_float_fftw_planner11create_planEii10dim_vectoriiiPKSt7complexIfEPS2_
00a61a14 S
__ZN25octave_float_fftw_planner11create_planEii10dim_vectoriiiPKSt7complexIfEPS2_.eh
00042f20 T __ZN25octave_float_fftw_planner6methodENS_10FftwMethodE
00a61950 S __ZN25octave_float_fftw_planner6methodENS_10FftwMethodE.eh
00042f10 T __ZN25octave_float_fftw_planner6methodEv
00000000 A __ZN25octave_float_fftw_planner6methodEv.eh
00046150 T __ZN25octave_float_fftw_plannerC1Ev
00a61aec S __ZN25octave_float_fftw_plannerC1Ev.eh
00045b50 T __ZN25octave_float_fftw_plannerC2Ev
00a61ab4 S __ZN25octave_float_fftw_plannerC2Ev.eh
          U _fftw_destroy_plan
          U _fftw_execute_dft
          U _fftw_execute_dft_r2c
          U _fftw_import_system_wisdom
          U _fftw_plan_many_dft
          U _fftw_plan_many_dft_r2c
00c26fa0 S _fftw_planner
          U _fftwf_destroy_plan
          U _fftwf_execute_dft
          U _fftwf_execute_dft_r2c
          U _fftwf_import_system_wisdom
          U _fftwf_plan_many_dft
          U _fftwf_plan_many_dft_r2c
00c26f40 S _float_fftw_planner
~/Development/octave $