Failed to load

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: 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
it returns: (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/

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!


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

1 Like

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!


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.

1 Like

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

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

@anelson: See @Pantxo’s comment:

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

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

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

which involves running

sudo ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/

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

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…

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.