octave-devel build: no graphics display found

[vic@…]

I just did a clean installation of octave-devel:

   sudo port install octave-devel +gcc47 +docs +fltk

The build went perfectly and octave now works---but with one serious problem that is announced immediately:

warning: no graphical display found

The latest port of aquaterm @1.1.1 is installed and active in my MacPorts system. I believe octave-devel should have picked this up during its compilation.

My homebrew octave, also @3.6.2,

   /usr/local/bin/octave

has no problem finding the MacPorts aquaterm.

[ryandesign (Ryan Carsten Schmidt)]

You will need to install X11—either ​Xquartz or the xorg-server port; have you done this already? What is the DISPLAY environment variable set to?

You mentioned Homebrew. Do you have Homebrew (and thus things in /usr/local) installed at the same time that you're using MacPorts? That's not supported and will cause problems. Please choose one package manager to use, and uninstall the other.

[michaelld (Michael Dickens)]

I'll look into this, but it's not a high priority I think. You can always create an octave configuration startup file that sets the graphics front end to use, such that it's ready to go from the first command line prompt.

[vic@…]

Replying to ryandesign@…:

You will need to install X11—either ​Xquartz or the xorg-server port; have you done this already? What is the DISPLAY environment variable set to?

You mentioned Homebrew. Do you have Homebrew (and thus things in /usr/local) installed at the same time that you're using MacPorts? That's not supported and will cause problems. Please choose one package manager to use, and uninstall the other.

Xquartz is installed. It has been since I installed Mountain Lion, some time ago. DISPLAY?

~$ echo $DISPLAY
/tmp/launch-IMFoxP/org.macosforge.xquartz:0

I don't believe there is any conflict with the Homebrew Octave on my system. My PATH reads

~$ echo $PATH
/usr/texbin:/opt/local/libexec/gnubin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin

MacPorts Octave is what I get with the command

~$ octave

I can only get the Homebrew Octave with the very specific

~$ /usr/local/bin/octave

unless the MacPorts Octave is dead. In any case, the two Octaves can run different projects independently. If it weren't for my Homebrew Octave, I wouldn't have had any Octave at all recently. The Homebrew Octave didn't get killed by the recent upgrade of gcc in MacPorts.

[vic@…]

Replying to michaelld@…:

I'll look into this, but it's not a high priority I think. You can always create an octave configuration startup file that sets the graphics front end to use, such that it's ready to go from the first command line prompt.

I have put

gnuplot_binary ("/opt/local/bin/gnuplot");

in ~/.octaverc. Now my MacPorts Octave executes "sombrero" beautifully in Aquaterm, as does my Homebrew Octave.

Both Octave versions are 3.6.2. The differences in the initial boilerplate are

MacPorts:

Octave was configured for "x86_64-apple-darwin12.1.0".
warning: no graphical display found

Homebrew:

Octave was configured for "x86_64-apple-darwin11.4.0".

The "no graphical display found" has only appeared since the rebuild of octave-devel after the gcc fiasco.

This is certainly no problem for me. I generally don't use Octave graphics; I use gnuplot directly. But I do believe Octave should be "finding" gnuplot by default.

[michaelld (Michael Dickens)]

What's going on is that during "configure", the provided compiler (MacPorts gcc of some version) is provided with a C++ file (conftest.cpp) but internally (via headers) some of the code is objective-c++ and the compiler isn't auto-switching to that language; hence, the test fails and the Carbon framework is not detected or used. Then when octave is executed there is no display detected (see "src/display.cc"). Thus, the real issue is that the new MacPorts' GCCs (at least gcc47) are not auto-selecting compile language correctly. I think this worked correctly a while back with MacPorts' GCCs; no idea what changed.

I'm trying to work around this by compiling just "src/display.cc" using an Apple compiler (which does do the auto-language selections correctly); it's the only file that uses HAVE_FRAMEWORK_CARBON, so this seems reasonable. It's all looking good so far; more later.

[michaelld (Michael Dickens)]

OK; should be fixed in r97995. I'm going to close this ticket, but if this fix doesn't work for you then reopen it and attach some info for me to work off of. I think my fix is pretty generic, but I might be wrong.