Failed to load liboctinterp.so.3

[Dyllo]

Hi everybody,

My system

• OS: Linux Mint 20
• Octave version: GNU Octave, version 5.2.0
• Installation method: sudo apt-get install octave

Problem description

I am working on an old shell script that calls octave at some point, with a file.m as argument.
The part of the code that causes the error just runs: octave -q my_file.m (and other arguments)

The error is: “select.oct: failed to load: liboctinterp.so.3: cannot open shared object file: No such file or directory”

The code uses to work with octave 4.4.1 on a server, but I can’t make it run on my PC, in local.

Do you think that if I install octave-4.4.1 it could fix the problem? Or do you think octaves’ version is unlinked to the issue? (As for the moment I have also tried compiling octave-4.4.1 from source but I am encountering a problem during compilation too, so I just want to be sure it could work.)

Or maybe this shared library has nothing to do with octave and I can get it elsewhere?
When I run:

ldconfig -p | grep liboctinterp.so.
it returns:
liboctinterp.so.7 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/liboctinterp.so.7

I think it means I need an older version of that shared library, but can’t find it… I think it uses to comes with octave-4.4.1?

I don’t really know what to do here. Any help is welcomed!

Best,
Lloyd

[mmuetzel]

Do you have access to the sources of select.oct?
You should re-compile the .oct file with the same version of Octave.

[Dyllo]

Hi mmuetzel,

I think I don’t have access to them, but I will double-check ASAP.
Thank you very much for that info, will keep you updated!

Best,
Lloyd

[Pantxo]

select.oct happens to be included in the parallel package. Are you using this package? If so then maybe all you have to do is update your packages, e.g. pkg update parallel.

[Dyllo]

Hi! Compiling the .oct files worked! Thank you for your comment!
Best, Lloyd

[anelson]

Hi,
I am running into a similar issue with the reported error above when octave is trying to read a .mex file from palm. Can someone mention where you found the select.oct file?

OS: Ubuntu 20.04
Octave: v5.2.0

[mmuetzel]

@anelson: See @Pantxo’s comment:

@Pantxo

pkg update parallel

Edit: Since you are also writing about a .mex file, it might also help recompiling that with your current version of Octave.

[fangq]

I also mentioned about this issue at the bottom of this post

Supporting mexext?

moving a recent post from mailing list to this forum, as suggested https://lists.gnu.org/archive/html/help-octave/2022-04/msg00014.html Dear group, I have been writing various toolboxes for octave and matlab - both as part of my research and hobby. I especially care about portability of my toolboxes, and often times spent quite a bit effort to ensure they can run across matlab and octave, as well as various OSes. One challenge I am facing is to deploy mex-based toolboxes. For example, when …

I have been suggesting a workaround to my users to get around this issue

https://groups.google.com/g/mcx-users/c/Kj4OZybYfAA/m/yjXXvVi4AgAJ

which involves running

sudo ln -s /usr/lib/x86_64-linux-gnu/liboctinterp.so.7 /usr/lib/x86_64-linux-gnu/liboctinterp.so.3

where liboctinterp.so.7 should be the version currently installed on your system, and liboctinterp.so.3 is the version that the binary oct/mex file was linked against.

[mmuetzel]

It’s probably not a good idea to create that symlink. There is a reason why those libraries are postfixed with the API version: There is no guarantee that the APIs are compatible across versions…

[fangq]

I agree. it is nothing more than a hack, however, in our case, it simply worked (and solved user’s problem without needing the pain to teach them to set up the compilation system).

I suspect that the reason it worked for us was because the mex APIs used in our mex file are the basic ones and among the stable subset of all APIs. I also suspect that the majority of simple mex files found online also satisfy this condition.