New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

octfiles are not compatible between Octaves with different installation paths #43

Open
apjanke opened this Issue Jul 19, 2018 · 2 comments

Comments

1 participant
@apjanke
Contributor

apjanke commented Jul 19, 2018

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

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 apjanke added this to Needs triage in Octave.app via automation Jul 19, 2018

@apjanke apjanke added this to the 4.4.0 milestone Jul 19, 2018

@apjanke apjanke self-assigned this Jul 19, 2018

@apjanke

This comment has been minimized.

Show comment
Hide comment
@apjanke

apjanke Jul 19, 2018

Contributor

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.

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.

Contributor

apjanke commented Jul 19, 2018

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.

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 apjanke moved this from Needs triage to High priority in Octave.app Jul 19, 2018

@apjanke apjanke modified the milestones: 4.4.0, The Future Jul 23, 2018

@apjanke

This comment has been minimized.

Show comment
Hide comment
@apjanke

apjanke Jul 23, 2018

Contributor

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.

Contributor

apjanke commented Jul 23, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment