MATLAB coder GUI / CLI shows cryptic errors: libmwboost / CUDA_CODEGEN

Hi, I hit a number of snags when using MATLAB coder. I'm using R2020a on Ubuntu 18.04 on an XPS 15 9570.

Issue no.1 (GUI): When I run the GUI, I am stopped at the automatically define input types step by the message

"Invalid MEX-file '/path/on/my/machine' : libmwboost_system.so.1.65.1: cannot open shared object file: No such file or directory.

However...

>> !locate libmwboost_system
/usr/local/MATLAB/R2020a/bin/glnxa64/libmwboost_system.so.1.70.0

Why doesn't MATLAB detect and use the latest version of this .so? How to fix this problem?

Issue no.2 (CLI): Raw C code is better than nothing. so I ran the command below and hit another snag

>> codegen -c foo
CRL: "CUDA_CODEGEN" cannot be found in the registry.
Use help codegen for more information on using this command.
Error using codegen

Googling for CUDA_CODEGEN doesn't even give relevant results. Before diving into debugging GPU issues, I need to emphasize that CUDA code generation is the absolute least of my concern. If there is a way to make Coder ignore CUDA and move on, I'd go with that.

I'm totally stalled now and I greatly appreciate any answer.

Both issues manifest with the simplest toy function like

function y = foo(x)
y = x;
end

[Ye Yang]

Hi Hei,

For problem (2) you are encountering, it looks like the CUDA library cannot be found for some reason.

Can you restart MATLAB and try the following command to see if it errors out?

crviewr('CUDA_CODEGEN')

If this errors out, can you check if the following directory is on MATLAB path?

<matlabroot>/toolbox/coder/foundation/tfl (on linux or mac)

<matlabroot>\toolbox\coder\foundation\tfl (on windows)

If it is not on the path, you will need to add it for codgen to work.

Thanks.

Ye

[Ye Yang]

Hi Hei,

In addition to the steps above, can you let us know some details how you use the codegen command?

e.g. Are you using a custom config object? If so, can you provide the command how you create the config objects?

This will also be helpful to identify and resolve the issue.

Thanks.

Ye

[Hei Shing Helson Go]

Thanks for the answer! I do have <matlabroot>/toolbox/coder/foundation/tfl on my MATLAB path.

>> exist('coder/foundation/tfl','dir')

ans =

     7

crviewer throws an error

>> crviewer('CUDA_CODEGEN')
Error using RTW.viewTfl
The specified code replacement library is not registered: CUDA_CODEGEN

Error in RTW.viewTfl

Error in crviewer - Show complete stack trace

I'm not using a custom config object.

If I can't bypass / disable the CUDA requirement, what is the version of cuda that MATLAB R2020a is compatible with?

[Ye Yang]

Hi Hei,

I do not think it is because of the CUDA requirement.

This library is unconditionally installed/loaded with/without CUDA, but it is somehow not accessible in your case.

Can you go to coder/foundation/tfl and check the followings?

(1) Are there .mat files with the names

private_cuda_codegen_tfl_table_tmw

private_cuda_cpu_codegen_tfl_table_tmw

private_cuda_cpu_sim_tfl_table_tmw

private_cuda_half_table_tmw

private_cuda_sim_tfl_table_tmw

(2) Is there a .mat file named rtw_default_targetInfo_tfl?

If so, you can load this matfile and do the following check:

thisTfl.Name

Can you check whether it contains 'CUDA_CODEGEN' and 'CUDA_SIM'?

If so, can you find index in thisTfl that corresponds to 'CUDA_CODEGEN' and check the contents there?

crviewer(thisTfl(idx))

Thanks.

Ye

[Hei Shing Helson Go]

Hi,

(1). I do have these files

(2). It does not contain CUDA_CODEGEN

From what you said, I think reinstalling MATLAB may help me...I used to have R2020a installed alongside R2019b earlier in the year when I upgraded. Also, my R2020a used to be on a license that does not provide Coder, until I moved to a newer license that does. I suppose something went wrong in one of these steps...

Please let me know asap if I should NOT do a reinstall, for any reason.

[Ye Yang]

Hi Hei,

Looks like your rtw_default_targetInfo_tfl.mat file was not updated.

It is possible to copy this file from another computer, but similar issues might happen with other files as well.

At this point, I strongly recommend to just do a reinstall.

Thanks.

Ye

[Hei Shing Helson Go]

Great! I reinstalled MATLAB and my problems gone away.

Coder is working. Thanks for your help!

To prevent this issue from resurfacing, would you recommend that I reinstall MATLAB and all toolboxes when I upgrade from R2020a to some future version? What about switching between licenses?

[falk]

Restart could also help!

Answer 1

[Walter Roberson]

"Invalid MEX-file '/path/on/my/machine' : libmwboost_system.so.1.65.1: cannot open shared object file: No such file or directory.
/usr/local/MATLAB/R2020a/bin/glnxa64/libmwboost_system.so.1.70.0
Why doesn't MATLAB detect and use the latest version of this .so? How to fix this problem?

You have different minor version numbers, 1.65 compared to 1.70 . The convention is that shared objects that differ in minor version numbers are entitled to be incompatible, but that changes in the release number, the third number in the triple, are intended to be bug fixes or compilation improvements that are intended to be compatible.

Therefore the linking process should not substitute 1.70.0 for 1.65.1 because as far as the linker can tell from the version numbers, the two might have different entry point numbers and different external symbol names.

The convention is that major version numbers such as the leading 1 correspond to major redesigns that might be barely recognizable in operation -- but in the meantime a change in minor version number is permitted to add or remove functions.

As boost deals a lot with templated C++ functions, it would be common for later versions to add functionality -- but it would also be common for later versions to lose internally generated symbols corresponding to changed implementation details .

[Hei Shing Helson Go]

I'm well aware of how versioning works but your explanation is super concise :) Pls allow me to paraphrase you when I explain software versioning to others.

I gather that libmwboost is MathWorks's own version of boost, libboost is the other version in Ubuntu repositories. There should be no relationship between one another.

I checked that my MATLAB ships with 1.70.0 versions of the shared objects only.

❯ locate libmwboost | grep 1.65 | grep -v Downloads
❯ locate libmwboost | grep 1.70 | grep -v Downloads
/usr/local/MATLAB/R2020a/bin/glnxa64/libmwboost_atomic.so.1.70.0
/usr/local/MATLAB/R2020a/bin/glnxa64/libmwboost_chrono.so.1.70.0
/usr/local/MATLAB/R2020a/bin/glnxa64/libmwboost_container.so.1.70.0

so on and so forth.

I asked around and found that R2019b ships with 1.65.1 versions. I had upgraded from R2019b to R2020a earlier in the year, so this might be why coder asks for libmwboost 1.65.1 even though R2020a ships with libmwboost 1.70.0.

So the question remains, unless coder IS intended to work with 1.65.1, in which case MATLAB shipped with the wrong version of libmwboost and I'm cooked.