Invalid MEX-file ‘/home/ari/acados/examples/acados_matlab_octave/getting_started/c_generated_code/acados_mex_create_pendulum.mexa64’: libacados_ocp_solver_pendulum.so: cannot open shared object file: No such file or directory
The file libacados_ocp_solver_pendulum.so exists in the folder /home/ari/acados/examples/acados_matlab_octave/getting_started/c_generated_code/
I’ve already tried adding the directory, and that didn’t help.
However, when I run:
$ ldd libacados_ocp_solver_pendulum.so
The output is:
linux-vdso.so.1 (0x00007ffdf1bfb000)
libacados.so => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f845d63c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f845d44a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f845d7f6000)
If I understand correctly, that is exactly where the Matlab code crashes.
This line is where it crashes:
ocp = acados_ocp(ocp_model, ocp_opts, simulink_opts);
That sounds indeed weird.
But I would expect a different kind of error in this case.
You can set the targets to GENERIC explicity to rule it out.
I’m trying to run minimal_example_ocp.m in Matlab 2023a on Ubuntu 20.04.
It is really confusing that you have some issues with this kind of setup because it seems very similar to what is used on the continuous integration tests on Github Actions
You can also maybe quickly check if the Python interface works.
I was able to solve the problem by adding the path to the generated C code to LD_LIBRARY_PATH: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/ari/acados/examples/acados_matlab_octave/getting_started/c_generated_code/
I followed the advice given here (the second suggestion):
Thank you very much. I had the same problem on Ubuntu 18.04 with Matlab 2019a and your solution solved it.
But I also noticed that the env.sh in the getting_started folder actually missed the following line (compared to other examples with generated C code, e.g. the generic_external_cost folder):
export LD_RUN_PATH=“$(pwd)”/c_generated_code
Adding this line to env.sh and sourcing it before running the example also worked. So it seems the env.sh should be updated.