[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macOS 4.4.0 DMG (beta2) ready for testing

From: Andrew Janke
Subject: Re: macOS 4.4.0 DMG (beta2) ready for testing
Date: Wed, 18 Jul 2018 16:27:50 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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
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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]