Minimal_example_ocp.m crashes with Invalid MEX-file error

Hi!
I’m trying to run minimal_example_ocp.m in Matlab 2023a on Ubuntu 20.04.
I ran the CasADi installation as instructed on the acados site (using ‘wget -q -nc --show-progress https://github.com/casadi/casadi/releases/download/3.4.0/casadi-linux-matlabR2014b-v3.4.0.tar.gz’ from the folder <acados_root_folder>/external).

The error I get is:

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

Error in pendulum_mex_solver (line 51)

  •        [obj.C_ocp, obj.C_ocp_ext_fun] = acados_mex_create_pendulum();*
    

Error in acados_ocp (line 211)

  •        obj.t_ocp = mex_solver();*
    

Error in minimal_example_ocp (line 80)
ocp = acados_ocp(ocp_model, ocp_opts, simulink_opts);

Any help will be much appreciated!!

Hi,

Can you check if the library libacados_ocp_solver_pendulum.so is there (in c_generated_code).
If yes, can you try to add the directory to your path?

If no, is there any error message before?

Best,
Jonathan

Thanks for the quick response!

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)

Is the “not found” a problem?

Thanks again!

I would have expected a different error in this case, something like

 libacados_ocp_solver_pendulum.so: cannot open shared object file: No such file or directory

But, did you check that the libacados.so is compiled correctly.
I.e. in <acados_root>/lib?

How can I tell if libacados.so compiled correctly?

This is the content of <acados_root>/lib:

I think that looks correct. Does your LD_LIBRARY_PATH contain this directory?

Yes it does:

$ env | grep LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-11.6/lib64:/home/ari/acados/examples/acados_matlab_octave/getting_started/…/…/…/lib:./build:/home/ari/acados/examples/acados_matlab_octave/getting_started/…/…/…/interfaces/acados_template/tera_renderer/t_renderer/target/release

Is there any error when creating the libacados_ocp_solver_pendulum.so, which happens when you create the Matlab OCP solver?

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);

During instalation, I noticed that the target is set to X64_INTEL_HASWELL even though my CPU is AMD Ryzen 7 5800H. Can this be a problem?

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 :thinking:

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):

Any idea why this is required?

Thanks again for all your help!

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.

4 Likes

I agree. It seems env.sh needs to be fixed.