Preparing for new Octave release

[kingcrimson@…]

Hi all,

Octave 3.8 is due to be released very soon so we are working to test and improve the way it works on OSX.

I thought I'd post the Portfile I am using to do the test builds here, so it might be useful when preparing the actual port once 3.8 is out.

Currently I do not have access to Mavericks so testing on Mavericks is particularly welcome.

Currently the attached patch is also required to work around a problem with qscintilla that causes a crash when syntax highlighting

[kingcrimson@…]

snapshot of octave sourcecode from repository

[kingcrimson@…]

portfile and patch

[mf2k (Frank Schima)]

Trac requires complete email addresses.

[cooljeanius (Eric Gallager)]

Cc Me!

[kingcrimson@…]

New version of portfile with fetch.type=hg

[kingcrimson@…]

Replying to kingcrimson@…:

Currently I do not have access to Mavericks so testing on Mavericks is particularly welcome.

The release of Octave 3.8 is now imminent. Since my first post I upgraded to Mavericks, so the the new version of the Portfile has been created and tested on Maveicks. Here's some notes about the building process:

• The qscintilla problem does not seem to affect Mavericks, but there is a different issue regarding fonts in QT which requires patching.

• including headers from both gnulib and QT requires patching all headers in the directory $prefix/include/Qsci to remove the lines

#ifdef __APPLE__
extern "C++" {
#endif

and

#ifdef __APPLE__
}
#endif

• I need to install GraphicsMagick specifying

configure.compiler=macports-gcc-4.8

on the command line to avoid errors for "symbols not found for architecture x86_64"

• Macports ghostscript will not work with this port, any attempt to print with ghostscript will result in error "cannot find default icc profile" and produce no output, this wil cause building the docs to fail as manual images are produced by running Octave.

I circumvented this issue locally by adding the ghostscript version installed by MacTex to the path during install. In the portfile I set the option -doc in the default variant to work around this issue.

• The portfile links to atlas only as I found both framework Accelerate and OpenBLAS to give incorrect results when running the Octave test suite.

• I tried various compiler combinations including clang+gfortran48, clang+gfortran47, clang+dragonegg but only building with gcc47+gfortran47 or gcc48+gfortran48 I managed to complete the build.

[michaelld (Michael Dickens)]

OK; interesting stuff. What I'm going to do sometime today or tomorrow -- I'm very close; everything works on 10.8 under GCC or Clang; I'm testing on 10.9 today with just Clang -- is update octave, octave-devel, and all of the octave-* ports. octave will replace octave-devel, and there will be only the 3.6 release of octave for a while. After a suitable amount of time, say, 2 months, I'll reinstate octave-devel to be the 3.8 release, after verifying/fixing the octave-* ports work with it.

"Why?" you ask ...

Most octave users are using octave-devel because it works; the current octave port (3.2.4_16) does not work for everyone, and especially folks using 10.7+; many/most folks have moved to octave-devel because they had no choice if they wanted octave, rather than because they wanted the latest octave. Because the 3.6 release is very stable, it makes sense to move it to octave; but, instead of putting the imminent 3.8 release as octave-devel right now -- which folks using the current octave-devel would be upgraded to if this were done immediately -- we set octave-devel as "replaced by" octave for a short time to get folks transitioned to using the octave port. Then after that short time I reinstate octave-devel -- there will always be hold-outs who do not update, but those will be many fewer than if I did the upgrade right now.

So, when we get a few months down the road I will figure out what makes sense for the Portfile to add the 3.8 release back in. Hopefully some of the stdlib issues will be fully resolved by then, as will some with GhostScript and other ports upon which octave depends.

BTW> Related: whatever happened to using itsol? I thought octave 3.8 was going to be using that port ...

[sebastian@…]

@michaelld: I would rather suggest to remove the octave-devel port completely and come up with "octave38" (or something similar). The port "octave" would be a dummy for "octave36". I never understood why a stable release ist denoted by "devel"... I made this remark already some time ago but I was not very successful. Hence I try again :)

@kingcrimson: 1) with your port file I run into the "Gets is a security hole" ​problem. Do I really have to patch the files of Qsci? This is ugly! How does this effect other ports? (If we cannot avoid this, I suggest to extract Qsci in the build directory, patch the files locally and include them. This is done also with other ports that require internal header files e.g. from TCL/TK) 2) I had to replace hdf5 by hdf5-18, 3) any progress regarding JIT?

Thanks to both of you, bye Sebastian

[sebastian@…]

Cc Me!

[michaelld (Michael Dickens)]

@sebastian: Using the "octave38" name implies that it can be installed at the same time as other octave ports, e.g., "octave36". This is standard naming in MacPorts that is true at least 90% of the time, and those others are always encouraged to get their act together. As I said in ​my email, I'm not going to go that route; I just don't have the time for it. I think having 1 usable active octave port is in everyone's best interest; and, eventually, the next generation of the stable release, too. My future octave-devel port (currently 3.7.7) seems to build and run just fine; I think I did not enable JIT just yet though. If you want to discuss any of this further, email me.

[michaelld (Michael Dickens)]

And, btw, I should be pushing these changes this morning (US/ET). I've verified that all of the usable octave modules build and load on both 10.8 and 10.9; now, it's just the moving octave-devel to octave and setting octave-devel as replaced by octave, temporarily.

[kingcrimson@…]

BTW> Related: whatever happened to using itsol? I thought octave 3.8 was going to be using that port ...

3.8 was not expected to be released at all, it was decided to make this intermediate release because the work needed to complete the work for 4.0 is taking much longer than anticipated but postponing the release of the GUI further was not an option given the strong demand for it.

ITSOL is on the 4.0 branch so as 4.0 is postponed ITSOL is postponed as well :(

[kingcrimson@…]

Replying to michaelld@…:

my future octave-devel port (currently 3.7.7)

Does that port need any of the fixes I am applying? does it work with clang?

seems to build and run just fine;

what do you mean by "run just fine"? did you try running run_test_suite does that return any failures? does setting editor fonts in the settings dialog work?

[michaelld (Michael Dickens)]

Yes, "make test" executes for the most part, with just a few failures most of which are expected. As with any "testing", it is impossible to test all possible features, so I'm sure there are ways in which it does not work ...

[mojca (Mojca Miklavec)]

Cc Me!

[kingcrimson@…]

Replying to michaelld@…:

Yes, "make test"

I guess you mean "make check", right?

Does your portfile include any fixes for the problems I reported in comment:3?

Most of the problems I see are with user interaction in the GUI so unfortunately they won't be cought by the tests.

Could you post your portfile somewhere (or email it to me if you prefer) so I can test it?

[michaelld (Michael Dickens)]

Autotools: make check ... CMake: make test ... so, yes, "make check" :)

I have not tried the GUI yet. Not enough time in the day ;)

I will attach to this ticket a diff between the (new) current octave Portfile and that which provides "octave-next" for folks to try out. Hopefully later today but I have work to do for a while now ...

[bpabbott@…]

I'm attaching a patch for 2.7.2 that removes each of the snippets below from the include files in Qt3/Qsci & Qt4Qt5/Qsci

#ifdef __APPLE__
extern "C++" {
#endif
and

#ifdef __APPLE__
}
#endif

[bpabbott@…]

patch for include files

[michaelld (Michael Dickens)]

@bpabbott: Are you saying that Octave 3.8.0rc1 will not build correctly with Qsci 2.7.2 without your patch?

[bpabbott@…]

Replying to michaelld@…:

@bpabbott: Are you saying that Octave 3.8.0rc1 will not build correctly with Qsci 2.7.2 without your patch?

Yes. I was unable to build Octave 3.7+ without the patch. See comment #3 by Carlo.

[michaelld (Michael Dickens)]

OK ... I'll get there tomorrow I guess, since I'm having other issues tonight.

Do you know if gl2ps integration work yet? I see "-lgl2ps" being used in places. I tried using it and fltk-devel, and the build errors out with:

/bin/sh ../libtool  --tag=CXX   --mode=link /usr/bin/clang++  -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -pipe -Os -arch x86_64 -stdlib=libstdc++ -D_THREAD_SAFE -pthread -avoid-version -module -no-undefined   -arch x86_64  -arch x86_64 -o dldfcn/__init_fltk__.la -rpath /opt/local/lib/octave/3.8.0-rc1 dldfcn/dldfcn___init_fltk___la-__init_fltk__.lo liboctinterp.la ../liboctave/liboctave.la -L/opt/local/lib -Wl,-headerpad_max_install_names -lfltk_gl -framework AGL -framework OpenGL -framework ApplicationServices -lfltk -lpthread -framework Cocoa -L/opt/local/lib -lfreetype  -L/opt/local/lib -lfontconfig -lfreetype  -Wl,-framework -Wl,OpenGL  -lm  
libtool: link: warning: `/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.2/../../../libgfortran.la' seems to be moved
libtool: link: warning: `/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.2/../../../libquadmath.la' seems to be moved
libtool: link: warning: `/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.2/../../../libgfortran.la' seems to be moved
libtool: link: warning: `/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.2/../../../libquadmath.la' seems to be moved
libtool: link: /usr/bin/clang++  -o dldfcn/.libs/__init_fltk__.so -bundle  dldfcn/.libs/dldfcn___init_fltk___la-__init_fltk__.o   ./.libs/liboctinterp.dylib -L/opt/local/lib -L/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.2 -L/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.2/../../.. ../liboctave/.libs/liboctave.dylib -lfltk_gl -framework AGL -framework OpenGL -framework ApplicationServices -lfltk -lpthread -framework Cocoa /opt/local/lib/libfontconfig.dylib /opt/local/lib/libfreetype.dylib -lm  -Os -arch x86_64 -pthread -arch x86_64 -arch x86_64 -Wl,-headerpad_max_install_names -Wl,-framework -Wl,OpenGL -Wl,-dylib_file -Wl,/opt/local/lib/octave/3.8.0-rc1/liboctave.2.dylib:/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_math_octave/octave-next/work/octave-3.8.0-rc1/liboctave/.libs/liboctave.dylib   -pthread -framework AGL -framework OpenGL -framework ApplicationServices -framework Cocoa
clang: warning: argument unused during compilation: '-pthread'
clang: warning: argument unused during compilation: '-pthread'
Undefined symbols for architecture x86_64:
  "_gl2psDisable", referenced from:
      glps_renderer::set_polygon_offset(bool, double) in dldfcn___init_fltk___la-__init_fltk__.o
      glps_renderer::set_linestyle(std::string const&, bool) in dldfcn___init_fltk___la-__init_fltk__.o
  "_gl2psEnable", referenced from:
      glps_renderer::set_polygon_offset(bool, double) in dldfcn___init_fltk___la-__init_fltk__.o
      glps_renderer::set_linestyle(std::string const&, bool) in dldfcn___init_fltk___la-__init_fltk__.o
  "_gl2psLineWidth", referenced from:
      glps_renderer::set_linewidth(float) in dldfcn___init_fltk___la-__init_fltk__.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [dldfcn/__init_fltk__.la] Error 1
make[3]: Leaving directory `/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_math_octave/octave-next/work/octave-3.8.0-rc1/libinterp'

I'll look into this tomorrow morning.

[michaelld (Michael Dickens)]

Without the Qsci patch (qsci in MacPorts is at 2.7.2 right now, not the latest which is 2.8.0), Octave 3.8.0rc1 builds just fine for me on 10.8 without gl2ps and without JIT (I have a variant for JIT, but haven't tried it yet). I'm building on 10.9 right now. Make check failures, details, and results:

  libinterp/corefcn/data.cc-tst .......................... PASS  852/853  FAIL 1

assert (log2 (complex (0,Inf)), Inf + log2 (i))
!!!!! test failed
ASSERT errors for:  assert (log2 (complex (0, Inf)),Inf + log2 (i))

  Location  |  Observed  |  Expected  |  Reason
     ()        Inf+NaNi   Inf+2.2662i    'NaN' mismatch

  libinterp/dldfcn/chol.cc-tst ........................... PASS   28/29   FAIL 1

 assert (cca'*cca,     ca, 16*eps);
 assert (ccau'*ccau,   ca, 16*eps);
 assert (ccau2'*ccau2, ca, 16*eps);

 assert (cca, ccal',  16*eps);
 assert (cca, ccau,   16*eps);
 assert (cca, ccal2', 16*eps);
 assert (cca, ccau2,  16*eps);
!!!!! test failed

  scripts/polynomial/roots.m ............................. PASS   11/12   FAIL 1

  ***** assert (roots ([1e-200, -1e200 * 1i, 1]), -1e-200 * 1i)
!!!!! test failed
ASSERT errors for:  assert (roots ([1e-200, -1e200 * 1i, 1]),-1e-200 * 1i)

  bug-38236.tst .......................................... PASS    0/1    FAIL 1

!!!!! test failed
'vr' undefined near line 1 column 36

  PASS     11454
  FAIL         4
  XFAIL        6
  SKIPPED     43

[michaelld (Michael Dickens)]

The new octave-gui works for me on 10.8; still building on 10.9. I used the "patch-qscintilla-lexer.diff" provided for the 3.7.7+ Portfile .. not sure if that was really needed.

[michaelld (Michael Dickens)]

Everything builds and functions on 10.9 as well for me. Make check failures, details, and results:

  libinterp/corefcn/dlmread.cc-tst ....................... PASS   12/20   FAIL 8

all 8 errors are like this one:
ASSERT errors for:  assert (dlmread (file),[1, 2, 3; 4 + 4i, 5, 6; 7, 8, 9; 10, 11, 12])
  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         real != complex

  libinterp/corefcn/sparse-xpow.cc-tst ................... PASS    1/2    FAIL 1

ASSERT errors for:  assert (sparse (2i) .^ [3, 4],sparse ([-0 - 8i, 16]))
  Location  |  Observed  |  Expected  |  Reason
    (1)      -1.4696e-15-8i      0-8i       Abs err 2.3054e-15 exceeds tol 0
    (2)      16-3.9189e-15i     16+0i       Abs err 4.3027e-15 exceeds tol 0

  libinterp/corefcn/str2double.cc-tst .................... PASS   28/31   FAIL 3

all 3 test errors are like this one:
ASSERT errors for:  assert (str2double (char ("1", "2 3", "4i")),[1; NaN; 4i])
  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         real != complex

  libinterp/dldfcn/chol.cc-tst ........................... PASS   28/29   FAIL 1

ASSERT errors for:  assert (cca' * cca,ca,16 * eps)
  Location  |  Observed  |  Expected  |  Reason
   (3,3)     16+5.5511e-17i       16        Abs err 3.5531e-15 exceeds tol 3.5527e-15

  scripts/io/importdata.m ................................ PASS   22/23   FAIL 1

ASSERT errors for:  assert (a,A)
  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         real != complex

  scripts/sparse/eigs.m .................................. PASS  152/153  FAIL 1

ASSERT errors for:  assert (max (abs ((A - d1 (i) * eye (n)) * v1 (:, i))),0,1e-11)
  Location  |  Observed  |  Expected  |  Reason
     ()       3.0465e-11       0         Abs err 3.0465e-11 exceeds tol 1e-11

  scripts/sparse/svds.m .................................. PASS    5/6    FAIL 1

ASSERT errors for:  assert (s2,s (k:-1:1),tol)
  Location  |  Observed  |  Expected  |  Reason
     .          O(6x1)       E(7x1)      Dimensions don't match

  scripts/specfun/realpow.m .............................. PASS    4/5    FAIL 1

assert (realpow (1i,2), -1)
realpow: produced complex result

  bug-38236.tst .......................................... PASS    0/1    FAIL 1

'vr' undefined near line 1 column 36

  io.tst ................................................. PASS   82/85   FAIL 3

all 3 errors are like this one:
 [val, count, msg, pos] = sscanf ("3I2", "%f");
 assert (val, 3);
 assert (count, 1);
 assert (msg, "");
 assert (pos, 2);
ASSERT errors for:  assert (val,3)
  Location  |  Observed  |  Expected  |  Reason
     .          O(0x1)       E(1x1)      Dimensions don't match

  PASS     11437
  FAIL        21
  XFAIL        6
  SKIPPED     43

[michaelld (Michael Dickens)]

On a related note, if I issue "plot(1:10)" in the GUI version, it crashes. Doing the same in the CLI version works just fine.

[michaelld (Michael Dickens)]

Patch (-p0) to dports/math/octave to add octave-next port, as of r114358

[michaelld (Michael Dickens)]

I just added the patch for octave-next. I'm curious if it works for anybody. You'll need to do a portindex (or sync or selfupdate) after patching to get port to believe the new port exists.

[bpabbott@…]

Replying to michaelld@…:

On a related note, if I issue "plot(1:10)" in the GUI version, it crashes. Doing the same in the CLI version works just fine.

Michael, where using the FLTK or Gnuplot toolkit? If the latter, were you using Gnuplot's Qt terminal? (that is known to be a problem).

[michaelld (Michael Dickens)]

>> graphics_toolkit
ans = fltk
>> available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}

Setting the graphics_toolkit to 'gnuplot' fixes the crash for me. gnuplot uses AquaTerm.app for me.

BTW> When starting up, octave-gui does "minimize -> restore" like 3 times. Any idea why?

[bpabbott@…]

Replying to michaelld@…:

>> graphics_toolkit
ans = fltk
>> available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}

Setting the graphics_toolkit to 'gnuplot' fixes the crash for me. gnuplot uses AquaTerm.app for me.

Ok. The problem is that the FLTK stuff isn't part of the main thread for the GUI. Native graphics on MacOS X will require the Qt toolkit. For now, the GUI should default to using Gnuplot.

BTW> When starting up, octave-gui does "minimize -> restore" like 3 times. Any idea why?

I see the same problem, but have no idea why.

[kingcrimson@…]

Replying to michaelld@…:

The new octave-gui works for me on 10.8; still building on 10.9. I used the "patch-qscintilla-lexer.diff" provided for the 3.7.7+ Portfile .. not sure if that was really needed.

define "works" can you open and save a file? c.

[kingcrimson@…]

Replying to michaelld@…:

The new octave-gui works for me on 10.8; still building on 10.9. I used the "patch-qscintilla-lexer.diff" provided for the 3.7.7+ Portfile .. not sure if that was really needed.

That patch disables auto indentation and syntax highlighting in the file editor, it is needed on 10.8 for me but not for 10.9. on 10.9 I need to apply the patches included in octave_3.8_rc1_portfile.tar.gz​.

Is there a way to tell macports to apply the patch only if building on 10.8?

c.

c.

[michaelld (Michael Dickens)]

Replying to kingcrimson@…:

Is there a way to tell macports to apply the patch only if building on 10.8?

Yes, though I prefer to not do this if/when possible.

[kingcrimson@…]

Replying to michaelld@…:

Everything builds and functions on 10.9 as well for me. Make check failures, details, and results:

PASS 11437 FAIL 21 XFAIL 6 SKIPPED 43

Here's my results installing your port on 10.9 using the gcc47 variant. Summary:

PASS 11441 FAIL 7 XFAIL 6 SKIPPED 53

I'll now have a look at what the failures are to see if there is anything critical.

c.

[sebastian@…]

Today, I have compiled octave-next with gcc48 on Mavericks: "sudo port -v build octave-next +atlas+gcc48+metis+doc configure.compiler=macports-gcc-4.8". I had to apply the qsci-headers patch and I had to add "-disable-jit" to "configure.args-append" in the Portfile of octave-next since I have LLVM 3.3 installed and this is not compiling octave correctly. My stats are slightly better than Carlos: PASS 11445, FAIL 3, XFAIL 6, SKIPPED 53.

libinterp/dldfcn/chol.cc-tst ........................... PASS 28/29 FAIL 1
bug-38236.tst .......................................... PASS 0/1 FAIL 1
system.tst ............................................. PASS 95/96 FAIL 1

The GUI is 1) not working correctly if started from terminal without sending the process to the background, 2) it is crashing e.g. when opening the preferences, 3) it flashes 3 times at startup.

[kingcrimson@…]

Hi Sebastian,

The GUI is 1) not working correctly if started from terminal without sending the process to the background,

How are you starting the GUI? If you are invoking octave-gui directly this is expected, you should "octave --force-gui" instead.

2) it is crashing e.g. when opening the preferences,

To work around this crash you can apply the patches I attached to this thread in the Octave tracker: ​https://savannah.gnu.org/bugs/?func=detailitem&item_id=40545

If you like I can send you an adapted portfile via mail.

3) it flashes 3 times at startup.

I see the same behaviour.

c.

[kingcrimson@…]

Replying to michaelld@…:

On a related note, if I issue "plot(1:10)" in the GUI version, it crashes. Doing the same in the CLI version works just fine.

Hi,

Octave does not actually need 'texlive-latex' at runtime and it doesn't need it at all even at build time unless building from mercurial sources as release tarballs include pre-built docs.

I'd suggest therefore removing this dependency from the Portfile.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #42026.

[sebastian@…]

Dear Michael, is there anything that I can do to make the octave 3.8 port happen? Me and my students are now using the official ​octave binary but this is not ideal because it's decoupled from the rest of macports (compilers, libraries etc).

[michaelld (Michael Dickens)]

Well .... it's been ~8 weeks since I bumped "octave" from 3.2 to 3.6 and made "octave-devel" replaced by "octave". That's probably enough time for folks to figure out upgrading, probably ... I have some stuff on my queue to do before I get to this, so it might still be a bit. Octave 3.6 does what I need, at least for now. Anyone else in a big rush to get octave 3.8 up and running in MacPorts?

[lockhart (Thomas Lockhart)]

Replying to michaelld@…:

Well .... it's been ~8 weeks since I bumped "octave" from 3.2 to 3.6 and made "octave-devel" replaced by "octave". That's probably enough time for folks to figure out upgrading, probably ... I have some stuff on my queue to do before I get to this, so it might still be a bit. Octave 3.6 does what I need, at least for now. Anyone else in a big rush to get octave 3.8 up and running in MacPorts?

I would love to run some MATLAB code containing calls to fminsearch. Octave 3.8 claims to have it...

[egon.geerardyn@…]

Cc Me!

[seanfarley (Sean Farley)]

Replying to michaelld@…:

Well .... it's been ~8 weeks since I bumped "octave" from 3.2 to 3.6 and made "octave-devel" replaced by "octave". That's probably enough time for folks to figure out upgrading, probably ... I have some stuff on my queue to do before I get to this, so it might still be a bit. Octave 3.6 does what I need, at least for now. Anyone else in a big rush to get octave 3.8 up and running in MacPorts?

Any progress on this?

[michaelld (Michael Dickens)]

Not by me. Haven't had time. Does the patch work for folks?

[seanfarley (Sean Farley)]

I can try 3.8.1 this week sometime.

[sebastian@…]

Maybe you should immediately aim for ​Octave 3.8.2.

[seanfarley (Sean Farley)]

Actually, I probably won't have any time to look at this :-(

[michaelld (Michael Dickens)]

Always aim for the latest release! Sorry to hear you won't have time, Sean. I wish I had more time, too (Octave 3.8, Qt 5.2, others). Maybe late summer, after Labor Day? I've got a crazy busy summer already planned!

[bpabbott@…]

For future reference, I'm able to build the 3.8.2 release using Macports for dependencies, but needed to make two modifications.

(1) Use the same gcc to build GraphicsMagick and Octave. For Octave, I used gcc-4.7, so I installed GraphicsMagick and instructed configure to use gcc-4.7 as well.

sudo port install GraphicsMagick +q32 configure.compiler=macports-gcc-4.7

The +q32 variant is also needed.

(2) Edit libgnu/stdio.in.h and remove the lines below.

/* It is very rare that the developer ever has full control of stdin,
   so any use of gets warrants an unconditional warning; besides, C11
   removed it.  */
#undef gets
#if HAVE_RAW_DECL_GETS
_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
#endif

[olmec@…]

Hi folks,

Cognisant of the fact that the maintainers have some time pressures; but thought it best to close the loop on the patches: the octave-diff.patch doesn't work; massive build errors that are not caught by the port dependencies.

The suggestion by bpabbott@… must be referring to 3.8.2-RC1? I don't see a 3.8.2 release yet? Nonetheless, many dependencies required for the 3.8.2-rc1, 3.8.1, 3.8.1-rc(1 to 4) snapshots to build, including fortran77 and others? Can anyone confirm this? I'm yet to succeed in building any of these snapshots. Suggestions?

Best,

M.

[bpabbott@…]

script to configure octave with dependencies from macports

[bpabbott@…]

I've attached the shell script I used to configure octave 3.8.x and above. I don't use any of the macports patches when building octave (I did for 3.6.x and below).

[olmec@…]

Cc Me!

[olmec@…]

Hi bpabbott@…; thanks for the script. It gets the configure across the finish line, but seems there are problems with the standard c++ library:

Making all in liboctave
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in cruft
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache g++-mp-4.7 -DHAVE_CONFIG_H -I. -I../..  -I../../libgnu -I../../libgnu -D_THREAD_SAFE -I/opt/local/include  -pipe -O2 -m64 -stdlib=libstdc++ -D_THREAD_SAFE -pthread -MT Faddeeva/libcruft_la-Faddeeva.lo -MD -MP -MF Faddeeva/.deps/libcruft_la-Faddeeva.Tpo -c -o Faddeeva/libcruft_la-Faddeeva.lo `test -f 'Faddeeva/Faddeeva.cc' || echo './'`Faddeeva/Faddeeva.cc
libtool: compile:  ccache g++-mp-4.7 -DHAVE_CONFIG_H -I. -I../.. -I../../libgnu -I../../libgnu -D_THREAD_SAFE -I/opt/local/include -pipe -O2 -m64 -stdlib=libstdc++ -D_THREAD_SAFE -pthread -MT Faddeeva/libcruft_la-Faddeeva.lo -MD -MP -MF Faddeeva/.deps/libcruft_la-Faddeeva.Tpo -c Faddeeva/Faddeeva.cc
g++-mp-4.7: error: unrecognized command line option '-stdlib=libstdc++'
make[4]: *** [Faddeeva/libcruft_la-Faddeeva.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Apropos, other projects compiled with the -stdlib=libstdc++ (or even libc++) don't complain at all... any suggestions. Is there a way I could substitute -lstdc++ instead?

Could we the dependencies be collated into a port file? Perhaps octave-devel? There are a few I haven't been able to resolve:

configure: WARNING: UNEXPECTED: nth_element test failed.  Refusing to fix except for g++ 4.8.2.
configure: WARNING: GLPK library found, but does not seem to work properly -- disabling glpk function
configure: WARNING: OpenGL libs (GL and GLU) not found.  Native graphics will be disabled.
configure: WARNING: CXSparse library not found.  This will result in some lack of functionality for sparse matrices.
configure: WARNING: ARPACK library found, but does not seem to work properly -- disabling eigs function
configure: WARNING: QAbstractItemModel::beginResetModel() not found -- disabling GUI
configure: WARNING: 
configure: WARNING: I didn't find the necessary libraries to compile native
configure: WARNING: graphics.  It isn't necessary to have native graphics,
configure: WARNING: but you will need to have gnuplot installed or you won't
configure: WARNING: be able to use any of Octave's plotting commands
configure: WARNING: 
configure: 
configure: NOTE: Libraries or auxiliary programs may be skipped if they are
configure: NOTE: not found OR if they are missing required features on your
configure: NOTE: system. 

I can't seem to spot the arpack problem either:

$port list arpack
arpack                         @3.1.5          math/arpack

Your guidance would be appreciated. I'm loathe to break from macports and install the octave .dmg from the forge.

Best, M.

[bpabbott@…]

Replying to olmec@…:

I suggest you first (1) install the most recent octave supported by Macports, (2) deactivate Macports Octave, and then (3) try to build Octave.

Using the proper variants is important.

sudo port install octave +atlas+docs+fltk+gcc47+x11

[seanfarley (Sean Farley)]

bpabbot, I have a version of this working which I'll upload later today but I didn't see the need for patching libgnu/stdio.in.h? Also, I have about 50 test failures with +accelerate. I'm going to try ATLAS and then the gui, and possibly jit, today and then maybe even commit it all. Also, I have 3.8.1 and 3.8.2-rc2 building with the same Portfile.

[bpabbott@…]

Replying to sean@…:

bpabbot, I have a version of this working which I'll upload later today but I didn't see the need for patching libgnu/stdio.in.h? Also, I have about 50 test failures with +accelerate. I'm going to try ATLAS and then the gui, and possibly jit, today and then maybe even commit it all. Also, I have 3.8.1 and 3.8.2-rc2 building with the same Portfile.

vecLib appears to have a lot bugs. I only use +atlas. The GUI works for me, but I have had trouble with JIT. My guess is that the problem lies in LLVM not being built with the same compiler as Octave.

[seanfarley (Sean Farley)]

A few notes about the portfile I have:

• use compilers port group to set up fortran variants
• drop patch files (apparently don't need the stdio.in.h patch)
• turn on parallel build
• add opengl to configure.args
• disable java
• add gui variant
• add jit variant
• change ui_msg into notes

I've noted that +gui and +jit are experimental so I don't think we need to worry too much about them now. Also, should we set graphics_toolkit("gnuplot"); in the site wide installation of octave since fltk crashes it?

[seanfarley (Sean Farley)]

I've attached a diff of the changes I mentioned above. I also added a feature to generate an Octave.app script for the +gui variant. If there are no objections, I'll push this out soon.

[cooljeanius (Eric Gallager)]

Replying to sean@…:

A few notes about the portfile I have:

• use compilers port group to set up fortran variants

Where is this done in the diff? The only place I noticed was in some of the context lines, and I thought context lines were unchanged ones...

• add opengl to configure.args

Personally I would wrap the addition of the --with-framework-opengl configure flag in a platform macosx conditional, like this:

platform macosx {
    configure.args-append \
        --with-framework-opengl
}

That would be just for technical correctness pedantry though, as OpenGL is only built as a framework for the macosx variant of platform darwin.
I doubt that anyone is actually using octave on a platform that is darwin but not also macosx though, so it would probably be okay to just leave it as is.

• disable java

Why is this necessary?

• change ui_msg into notes

While you are at it, I would try to be a bit more balanced with the recommendation to use the +atlas variant. While it may be true that the +atlas variant has fewer bugs (taking your word for it), the tradeoff that users make in exchange for the bug reduction is the commitment to spending a really long time building the atlas port. Personally I feel that this tradeoff is worth mentioning, but then again, I suppose that the notes are already long enough as it is...

[seanfarley (Sean Farley)]

Replying to egall@…:

Replying to sean@…:

A few notes about the portfile I have:

• use compilers port group to set up fortran variants

Where is this done in the diff? The only place I noticed was in some of the context lines, and I thought context lines were unchanged ones...

It's in another diff. I provided this shorter one so we could concentrate on the meat of the update.

• add opengl to configure.args

Personally I would wrap the addition of the --with-framework-opengl configure flag in a platform macosx conditional, like this:

platform macosx {
    configure.args-append \
        --with-framework-opengl
}

That would be just for technical correctness pedantry though, as OpenGL is only built as a framework for the macosx variant of platform darwin.
I doubt that anyone is actually using octave on a platform that is darwin but not also macosx though, so it would probably be okay to just leave it as is.

I could go either way on this. I think it can be changed when the need arises.

• disable java

Why is this necessary?

No particular reason other than copied from bpabbott's script.

• change ui_msg into notes

While you are at it, I would try to be a bit more balanced with the recommendation to use the +atlas variant. While it may be true that the +atlas variant has fewer bugs (taking your word for it), the tradeoff that users make in exchange for the bug reduction is the commitment to spending a really long time building the atlas port. Personally I feel that this tradeoff is worth mentioning, but then again, I suppose that the notes are already long enough as it is...

Yeah, agreed. I use +accelerate everywhere and haven't experienced any bugs yet.

Any other comments? I had to remove the +jit because I couldn't get it to build and have run out of time on this.

[seanfarley (Sean Farley)]

Full Portfile proposal for 3.8.1

[seanfarley (Sean Farley)]

I've attached the newest version of the file I have. I think the comments from above about JIT and Java can be bikeshedded later (just a revbump needed). Any other concerns before I push this? I think the Octave.app in +gui is cool, for what it's worth :-)

[sebastian@…]

If somebody is interested, I have made a script that creates a similar Octave.app bundle for homebrew with nice icons which allows to open m-files by double clicking, see here ​https://github.com/schoeps/homebrew-science_apps/blob/master/octave-app.rb. Feel free to use.

[seanfarley (Sean Farley)]

Replying to sebastian@…:

If somebody is interested, I have made a script that creates a similar Octave.app bundle for homebrew with nice icons which allows to open m-files by double clicking, see here ​https://github.com/schoeps/homebrew-science_apps/blob/master/octave-app.rb. Feel free to use.

Heh, yeah, I borrowed heavily from your script :-)

[dale+macports@…]

Cc Me!

[seanfarley (Sean Farley)]

Ok, I'm going to push this out later today unless there are any objections.

[seanfarley (Sean Farley)]

Pushed in r121950. Future updates in the 3.8.x should be straight-forward. I'll mark this close and suggest that improvements or bugs be put in new tickets.