oct-files are not compatible between Octaves with different installation paths

[apjanke]

This is related, but not identical, to #91.

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.

[~/octave/control-3.1.0/x86_64-apple-darwin17.6.0-api-v52]
$ 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)

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.

A real fix for this requires changes to Octave itself and how it builds octfiles. This is being investigated upstream at https://savannah.gnu.org/bugs/index.php?53627

In the mean time, we'll do what we can to isolate Octave.app from other Octave installs.

Mailing list thread: http://lists.gnu.org/archive/html/octave-maintainers/2018-07/msg00101.html

[apjanke]

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.

octave-app/octave-app-bundler@ee0c5a3

This will keep packages from crashing Octave, but won't fix the general problem with octfiles.

It also has the downside that all packages must be reinstalled for each version of Octave.app.

[apjanke]

I moved the milestone for this from 4.4.0 to The Future, because the full fix requires upstream changes in Octave itself to prevent the path-specific linkage at oct file build time.

I think the current approach we have of version-specific pkg directories is the best we're going to get for 4.4.0 and 4.4.1.