You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Currently, Octave builds octfiles by linking them with liboctave and liboctinterp at build time. This means they are linked with the full paths to those dylibs inside the Octave installation.
$ otool -L __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)
This results in octfiles that can only be used by an Octave installed at the same exact location as the one that originall produced the octfiles. Attempting to use those octfiles in other Octaves will cause them to crash.
This means that:
packages installed by Octave.app are not compatible with a Homebrewed or custom-installed Octave, and vice versa.
octfiles built in Octave.app are not compatible with Homebrewed or custom-installed Octaves, and vice versa.
octfiles and packages built by a Homebrewed Octave are not compatible with other versions of Octave, since the full Octave version is part of the path to the Octave keg inside the Homebrew cellar.
I have modified Octave.app to redirect its pkg installation location to a separate Octave.app-specific location, to avoid conflicts with Homebrewed Octaves, and to keep each Octave version separate, since the Octave version is part of the install path for Octave.app.