octave-maintainers
[Top][All Lists]
Advanced

[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: Tue, 17 Jul 2018 04:31:05 -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:47 AM, Andrew Janke wrote:
This one, I can reproduce. I installed "control" using Octave.app, and when I
try to run it under my Homebrewed octave:

octave:1> pkg load control
octave:2> bode(ss(-1, 1, 1, 0))
fatal: caught signal Abort trap: 6 -- stopping myself...
[1]    63078 abort      octave


And vice versa, Octave.app crashes if I try to use a "control" package installed
from the Homebrewed octave.
I can also reproduce this crash when running Homebrewed Octaves installed at
different paths, so I don't think it's specific to the Octave.app packaging.

Here's what I see when looking at the compiled octfiles (is that the right term?) in
the control package:

$ pwd
/Users/janke/octave/control-3.1.0/x86_64-apple-darwin17.6.0-api-v52
$ ls
PKG_ADD                          __control_helper_functions__.oct __control_slicot_functions__.oct
$ otool -L __control_helper_functions__.oct
__control_helper_functions__.oct:
    /usr/local/opt/octave/lib/octave/4.4.0/liboctinterp.5.dylib (compatibility version 6.0.0, current version 6.0.0)
    /usr/local/opt/octave/lib/octave/4.4.0/liboctave.5.dylib (compatibility version 6.0.0, current version 6.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

They are linked to liboctinterp and liboctave with the full path to the Octave installation.

I think that means that the compiled package can only be used with an octave installed
at the same location as the original octave that did the "pkg install". That would also explain
why upgrading a Homebrewed Octave causes packages to start crashing and requires
a reinstall of them.

I think we could work around this in Octave.app by having it install its packages to ~/octave-app/<version>
instead of the default ~/octave. (If that works, we may want to have the Homebrew Octave
formula do something similar. Depending on how important avoiding the package crashes is.)

This would still be an issue for having multiple Octaves installed at different locations on a
system. For example, if you had one at /opt/octave and another at /opt/octave-openblas.

That may have been one of the motivations for https://savannah.gnu.org/bugs/?53627
and  http://hg.savannah.gnu.org/hgweb/octave/rev/fa66d81d0956
("don't link .oct files with liboctinterp or liboctave").

Cheers,
Andrew

reply via email to

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