Re: macOS 4.4.0 DMG (beta2) ready for testing

[Andrew Janke]

On 7/17/18 3:33 PM, sshah wrote:
> With Beta 5 App, I still get Internal Error 4 unless I set F77 to the system
> gfortran.  Then it installs the control package in the ~/octave-app/4.4.0
> directory and the package works without interfering with the Homebrew
> version.
Darn it. I really thought that was going to work.

The good news is that I can reproduce it: I have a Mid 2012 Retina MacBook
Pro with an Ivy Bridge Core i7, and installing control with pkg in beta5
throws the same error.

>> pkg install -forge control
<built-in>: internal compiler error: Illegal instruction: 4
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [slicotlibrary.a] Error 1
make: *** Waiting for unfinished jobs....

So I should be able to diagnose and fix this.
> However, with this workaround, my own .oct files from the homebrew version
> in my local directory can not be used in the App as they are linked to the
> corresponding dynamic libraries.
>
> It would be much nicer if the dynamic libraries can be shared between the
> App and the Homebrew versions of octave.  If one can detect in the App that
> the correct homebrew version is already installed on the system, perhaps
> that can be used by the App for both pkg install and for running .oct files.
I don't know that we'll be able to fix this octfile incompatibility 
without changes
in Octave itself. (This bug may take care of it, if it is expanded to cover
macOS: https://savannah.gnu.org/bugs/index.php?53627)

I agree that this is a problem, so I'll watch that issue and see if
macOS support can be added.

We *could* have the Octave.app launcher script detect Homebrew-installed
Octaves and switch to using them at run time. But I think that would really
complicate its setup and cause problems for supporting it; Octave.app's
main goal is to be a simple, easy-to-install Mac distribution, so I think we
would prioritize keeping it simple.
> In any case, if the App version remains incompatible with the Homebrew
> version, it is a non-starter for me.  I would rather have a command line
> invocation octave --gui  that is compatible with its non-gui version through
> Homebrew than an incompatible App.
Sorry if it's not going to work out for you.

We plan on contributing our GUI-related fixes back to the main Homebrew
Octave formula, so some time soon this GUI support should be available to
you through that channel, too.

(We also currently provide a custom octave-octave-app Homebrew formula that
allows you to install our Qt-enabled  build under Homebrew, but it 
currently has
the same octfile link path compatibility issues as Octave.app does, 
because it
installs to a different path than the default Homebrew octave formula. 
Now that
I know about the octfile issue; we'll reconsider that behavior and maybe 
have
it install to the same path if there is demand for it. (The downside 
there is that
then you couldn't install the default Homebrew octave and our octave 
side-by-side
for comparison.))

Thanks regardless for helping us test this and unearth these issues!

Cheers,
Andrew