octave: 2.9.15 doesn't compile on Leopard; 3.0.0 is available

[charles.smart@…]

Octave doesn't compile from a clean install of macports on leopard. I installed macports on an otherwise blank system and then ran "sudo port install octave". After successfully building its dependencies, the following error message came out:

--->  Fetching octave
--->  Attempting to fetch octave-2.9.15.tar.bz2 from ftp://ftp.octave.org/pub/octave/bleeding-edge/
--->  Verifying checksum(s) for octave
--->  Extracting octave
--->  Applying patches to octave
--->  Configuring octave
--->  Building octave with target all
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_octave/work/octave-2.9.15" && make all " returned error 2
Command output: make -C testfun all
making PKG_ADD
ls: *.cc: No such file or directory
make -C time all
making PKG_ADD
ls: *.cc: No such file or directory
/opt/local/bin/g++-mp-4.2 -O2 -o gethelp gethelp.cc -L/opt/local/lib
./mkdoc . > DOCSTRINGS.t
mv DOCSTRINGS.t DOCSTRINGS
make -C doc all
making conf.texi from conf.texi.in
make -C faq all
makeinfo --html --ifinfo --no-split --output=Octave-FAQ.html -I.. -I. -I./.. Octave-FAQ.texi
make -C interpreter all
make -C ../../src DOCSTRINGS
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
making DOCSTRINGS
DOCSTRINGS is unchanged
make -C ../../scripts DOCSTRINGS
make[4]: `DOCSTRINGS' is up to date.
/opt/local/bin/g++-mp-4.2 -O2 -o munge-texi munge-texi.cc -L/opt/local/lib
making arith.texi from arith.txi
/bin/sh: line 1: 79233 Segmentation fault      ./munge-texi -d ../../src/DOCSTRINGS -d ../../scripts/DOCSTRINGS < arith.txi > arith.texi-t
make[3]: *** [arith.texi] Error 139
make[2]: *** [interpreter] Error 2
make[1]: *** [doc] Error 2
make: *** [all] Error 2

Error: Status 1 encountered during processing.

[ryandesign@…]

octave 2.9.17 is supposed to work better on Leopard. See #13332 for this request.

[jmpp@…]

To the original poster: please read WikiFormatting to learn how to properly paste terminal output: you should use the {{{ }}} pre-formatted text macro, thanks!

-jmpp

[waterson@…]

If you rebuild munge-texi using g++ instead of /opt/local/bin/g++-mp-4.2, you can restart the build and things seem to go along just fine. munge-texi appears to simply be a C++ utility program that preprocesses doc files. So this hack should get things rolling just fine -- maybe some makefile trickery is all that's needed here to use the "stock" compiler.

But that said, there are deeper problems here. After "fixing" the above problem, the build runs to completion, but the resulting octave executable dumps core on startup. :(

[waterson@…]

In the "flailing around trying random stuff" department, I tried...

• Building with Apple's gcc-4.2 and gfortran-mp-4.2 (since Apple's .dmg didn't include fortran). This built, but segfaulted on startup.
• Building with gcc-mp-4.3, except for gfortran-mp-4.2 (since octave's configure freaked out about gfortran-mp-4.3). The build busted early on due to some C++ hygiene problems.

I think that the problem comes down to g++-mp-4.2 generating bad files on Leopard, but I really don't have the chops to figure out what's going on there...

[waterson@…]

On Leopard, I was able to build octave-3.0.0 (that starts!) with gcc43 +gfortran and one very minor configuration tweak (making sure to include -lmetis in CHOLMOD_LIBS). My ports-fu is too weak to attempt updating the portfile, but here is the configuration I used (which is materially identical to the one in the current portfile):

CXXFLAGS='-O2' \
CFLAGS='-O2' \
CPPFLAGS='-I/opt/local/include' \
CPP='/opt/local/bin/cpp-mp-4.3' \
CXX='/opt/local/bin/g++-mp-4.3' \
F90FLAGS='-O2' \
SED='/opt/local/bin/gsed' \
LDFLAGS='-L/opt/local/lib' \
FCFLAGS='-O2' \
OBJC='/opt/local/bin/gcc-mp-4.3' \
INSTALL='/usr/bin/install' \
F90='/opt/local/bin/gfortran-mp-4.3' \
FC='/opt/local/bin/gfortran-mp-4.3' \
FFLAGS='-O2' \
OBJCFLAGS='-O2' \
AWK='/opt/local/bin/gawk' \
F77='/opt/local/bin/gfortran-mp-4.3' \
CC='/opt/local/bin/gcc-mp-4.3' \
./configure --prefix=${HOME}/octave-3.0.0 --enable-shared --enable-dl \
--disable-static --with-hdf5 --with-fftw --without-mpi \
--with-blas="-framework Accelerate"

Hope this helps...

[marcuscalhounlopez@…]

Attached is a proposal for version 3.0.0.
It compiles on Leopard (i386) and does not segfault at startup.
The tradeoff is that it requires either g95 or gcc43 as the Fortran compiler.
There is also no test to ensure that gcc43 was installed with the +fortran variant.

P.S. Could I be added to the cc?

[ryandesign@…]

Alejandro Aragon reported this issue again on macports-users.

[ryandesign@…]

I'm closing #13332 and we'll handle the update to 3.0.0 in this ticket. See #13332 for another attempt at an upgrade to 3.0.0.

[alakazam@…]

I can confirm that the Portfile submitted by Marcus compiles and executes correctly (Leopard 10.5.2) and would be a welcome update from the currently available Portfile version for octave.

[alakazam@…]

I also think that after upgrading octave to version 3.0.0, this will render the octave-forge port obsolete. Can someone confirm that the octave "pkg" command is bundled automatically into octave 3, and that this does make installing octave-forge obsolete ?

[jmpp@…]

The port maintainer, stechert, seems to be inactive at the moment. Any other project member could commit the changes proposed here, since our 72hrs timeout rule has been long in effect, but not having the maintainer's eyes to review stuff it would be great if we could have two extra things:

1. A diff of this proposed Portfile against the current one in our tree, to easily spot the changes;
2. An assurance that "stuff" wont break with these changes, since it's unlikely that any random committer will go through all the trouble to test the updates before committing them (which is exactly what maintainers are for)

Thanks!

-jmpp

[alakazam@…]

diff between current Portfile and proposed Portfile

[alakazam@…]

I have attached a diff between the current Portfile and the proposed Portfile. The additional patch files currently present in the macports tree are no longer required.

However, I realise that the proposed Portfile is not a minimalistic upgrade from the current Portfile, and does quite a bit of reformating in addition to upgrading the port. This might be better done in two commits. I can propose if required two Portfiles (and corresponding diffs), the first fixing the port, the second applying the proposed reformating changes.

Nothing in the octave port should be broken following this upgrade. the octave-forge port, which does not currently compile and is probably rendered obsolete by octave 3.0.0, will need to be upgraded.

As octave 3.0.1 has been released last week, I will work on upgrading the Portfile this week. As it is a minor bugfix version, and as no problems with version 3.0.0 have been directly reported by macports users, I still think upgrading to 3.0.0 in the meantime is interesting.

[takeshi@…]

I am going to commit changes to 2.9.15. * added additional checksums (sha1 and rmd160). * added a dependency to curl. * removed MACOSX_DEPLOYMENT_TARGET (#13217). I think it is good to have this version that builds before a major upgrade.

Since Octave 3.0 is significantly different from Octave 2.1.x, shouldn't we have a separate port (octave3)?

[andrea.damore@…]

Replying to takeshi@macports.org:

Since Octave 3.0 is significantly different from Octave 2.1.x, shouldn't we have a separate port (octave3)?

I second this.

[bcbarnes@…]

Replying to andrea.damore@macports.org:

Replying to takeshi@macports.org:

Since Octave 3.0 is significantly different from Octave 2.1.x, shouldn't we have a separate port (octave3)?

I second this.

I disagree. The current port is 2.9.x; and according from the http://www.gnu.org/software/octave/ frontpage, "As noted on the download page, 2.9.15 is a pre-release version of Octave 3.0. It is significantly different from Octave 2.1.x,..."

So, Octave 3.0.0/3.0.1 should be more similar to 2.9.x than 2.1.x.

[aronnax@…]

How about create an octave2 port so that installing "octave" gives you the latest version by default?

[aronnax@…]

I use Octave a lot; I don't speak for everyone but I have no reason to have an old version of it lying around.

[alakazam@…]

I also use octave a lot ; the differences between octave 2.9.* and 3.0.0 are minor. Most of the differences between octave 2.1 and 3.0 are compatibility upgrades so that octave is more compatible with matlab : improved plotting functionality, API changes in order to align the output of some functions on matlab. The last change is with built in variables, which I think few people tamper with anyway. The list of changes is available here : http://www.gnu.org/software/octave/NEWS-3.html

I think it is in the interest of most (if not all) users of octave to upgrade to 2.9. It might be interesting if some users request it to maintain a Portfile for octave 2.9, but I have not seen any major changes between 2.9 and 3.0, and since all of macports users are already using octave 3.0, I am not convinced having two separate ports is adequate.

Furthermore, octave-forge (a set of many additional "modules" containing functions for image manipulation, advanced statistical calculations, etc.) is compatible with octave 3.0.1 and "Many packages will also function function with earlier versions of Octave 2.9", so I think this too should be a reason to upgrade rather than branch into a new port. (Recent News section at http://octave.sourceforge.net/)

[andrea.damore@…]

Replying to bcbarnes@gmail.com:

I disagree. The current port is 2.9.x; and according from the http://www.gnu.org/software/octave/ frontpage, "As noted on the download page, 2.9.15 is a pre-release version of Octave 3.0. It is significantly different from Octave 2.1.x,..." So, Octave 3.0.0/3.0.1 should be more similar to 2.9.x than 2.1.x.

You're definely right, I misread 2.1.x and tought that 3.0 was very different from 2.9 so it would have been safer have two ports to not eventually break anything. My bad.

[takeshi@…]

I didn't read those descriptions. Sorry. Let's leave octave as a single port.

[alakazam@…]

I propose closing this ticket (the Portfile has been fixed), and continuing the "upgrade octave port to 3.0.x" on #15222 where I have proposed a Portfile upgrade.

[takeshi@…]

Committed octave 3.0.1 (#15222). Closing this ticket.