Re: macOS 4.4.0 DMG (beta2) ready for testing

[Mario Kleiner]

apjanke-floss wrote
> Hi, Mohammed,
> 
> I think I have a fix for this now.
> 
> It looks like packages that have compiled components cannot be shared
> between Octaves that are installed at different paths, because their dylib
> links include the full path to the liboct and liboctinterp they were
> linked
> against.
> 
> So, I think your issue is that your control package was built and
> installed
> by a different Octave, so it's incompatible with the Octave.app that lives
> at a different path.
> 
> To fix this, I've modified Octave.app to store its packages in a separate,
> versioned directory.
> 
> The downside is that you'll have to reinstall all your packages with each
> Octave.app version upgrade. The upside is that your Octave won't crash. I
> think it's worth the tradeoff.

Hi all,

there is a way to probably make .oct files independent of the absolute
octave install path, but it requires modification to octave itself. I can
only sketch it out, never tried the full solution myself, as that would
require patching octave itself, but i use half of this as part of a hack to
make my toolbox Octave mex files work under such situations:

You can encode a relative path into the .oct/.mex file aka dylib to the
install location of liboctinter/liboctave.
There may be more elegant ways, maybe some linker options, but this is the
hack i use, rewriting the the
path's after the .mex file was generated:

    % Build full path to our mex file:
    mexfname = [mexpath mexfname '.' mexext];

    % This is how the libdir should be defined automatically:
    libdir = __octave_config_info__.octlibdir;

    % This is sadly how we have to do it with Octave-4.2 on OSX 10.12
    % - Hardcoding the path for a Octave-4.2 install from HomeBrew. Yes,
this is sad...
    libdir = '/usr/local/opt/octave/lib/octave/4.2.0';

    % Replace absolute path to liboctinterp.4.dylib with @rpath:
    system(['install_name_tool -change ' libdir '/liboctinterp.4.dylib
@rpath/liboctinterp.4.dylib ' mexfname]);

    % Replace absolute path to liboctave.4.dylib with @rpath:
    system(['install_name_tool -change ' libdir '/liboctave.4.dylib
@rpath/liboctave.4.dylib ' mexfname]);

    % Add one single rpath: @loader_path. This is the path to our folder
where our
    % mex file is stored. If we place copies of liboctave.4.dylib and
liboctinterp.4.dylib
    % there, then the linker will find them. In absence, the linker will
also search the
    % users $HOME/lib/ directory as a possible fallback:
    lpaths = { '@loader_path' };

    % Add all paths in lpaths as potential search paths for the octave
    % library directories, ie., as settings for @rpath:
    for i = 1:length(lpaths)
        system(['install_name_tool -add_rpath ' lpaths{i} ' ' mexfname]);
        fprintf('Added Octave-4 @rpath %s to mex file %s ...\n', lpaths{i},
mexfname);
    end

This would encode the file to liboctinterp.4.dylib in the .mex/.oct file as:
@rpath/liboctinterp.4.dylib

My hack then sets @rpath to some generic location in the users directory
that i
have control over during installation of my toolbox.

But the proper way would be to define @rpath from within the octave
executable,
ie. octave during its own build defines @rpath for all its extensions.

Yet another variant would be adding an rpath like
install_name_tool -add_rpath @executable_path/. a.out

so @rpath is always some path relative to the install location of the octave
executable.
That approach didn't work for me with HomeBrew et al., because the octave
version
was encoded into the path to liboctinterp multiple times in a way that
defeated the use
of @executable_path

This link - especially the section about rpath - would show the probably
best way
to do it:

https://wincent.com/wiki/@executable_path,address@hidden@rpath

I think there was even a proposal of somebody many years ago to add this to
octave,
probably even with a proof of concept patch, but it didn't get much
feedback.

Best,
-mario


If you have a chance, please download the new Octave.app 4.4.0 beta5 build
and see if that works for you. When you install and run it, you should see
no packages installed under "pkg list", but a "pkg install -forge control"
should succeed, and should not interfere with the packages installed under
your other Octave installations.

https://github.com/octave-app/octave-app/releases/download/v4.4.0-beta5/Octave-4.4.0-beta5.dmg

References:
http://lists.gnu.org/archive/html/octave-maintainers/2018-07/msg00101.html
https://github.com/octave-app/octave-app-bundler/issues/42
https://github.com/octave-app/octave-app-bundler/commit/ee0c5a38469d4c9ed9c82dc1b0edd8637debcf45

Cheers,
Andrew



--
Sent from:
http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html