MATLAB coder GUI / CLI shows cryptic errors: libmwboost / CUDA_CODEGEN
15 visualizaciones (últimos 30 días)
Mostrar comentarios más antiguos
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
8 comentarios
Respuestas (1)
Walter Roberson
el 4 de Ag. de 2020
"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 .
Ver también
Categorías
Más información sobre Introduction to Installation and Licensing en Help Center y File Exchange.
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!