Revision history [back]

I have done some matlab integration with ROS, but not using the library compiler. Rather I have used the code generator for simulink which produces more or less raw C or C++ that integrates easily without dependencies. So I am not familiar with MCR or how that operates.

What it looks like(guess on my part), is that the Matlab shared C runtime libraries Matlab is using and loading at runtime differ from what your ros core libraries are compiled with. Maybe different versions. So when ROS is asking for this _ZN6... function that exists in the standard library it was compiled against, it is looking for it in the already loaded shared c library that matlab is using, but it isn't there.

This is a guess based on a quick google search I did of that function name that's missing, and the few folks that have similar problems (not with ROS but with other environments) seem to point in that direction. Anyway, that's what I would look at first, granted that is a guess on my part.

I know that matlab ships with a compiler, runtime and a complete infrastructure...but I don't recall what version it uses.

Net net, probably not a simple solution...but what I would do if run an MCR program and investigate what shared libraries it loads. Do the same for a ROS application. Look particularly to see if different versions of the same-named shared libraries are being loaded. From that you can identify the offender. If that's the case, the fix...may be easy or not easy.

1) how old is your matlab? Might be that another newer version has updated C++ libraries and that may solve the problem. 2) you could recompile ros core libraries against the matlab headers and libraries. Alternatively, you could see if matlab might accept your ROS runtime libraries. Either way, there are risks.

But first things first...see what the respective environments are loading in terms of shared libraries and see if this is the issue at all. On windows one could use "dependency walker" to see what shared library dependencies exist for an application...on linux, not sure what'd be best. But certainly no shortage of utilities.

Good luck...these kinds of issues are very frustrating. I live with them daily as integrate ros in a number of different environments.

I have done some matlab integration with ROS, but not using the library compiler. Rather I have used the code generator for simulink which produces more or less raw C or C++ that integrates easily without dependencies. So I am not familiar with MCR or how that operates.

What it looks like(guess on my part), is that the Matlab shared C runtime libraries Matlab is using and loading at runtime differ from what your ros core libraries are compiled with. Maybe different versions. So when ROS is asking for this _ZN6... function that exists in the standard library it was compiled against, it is looking for it in the already loaded shared c library that matlab is using, but it isn't there.

This is a guess based on a quick google search I did of that function name that's missing, and the few folks that have similar problems (not with ROS but with other environments) seem to point in that direction. Anyway, that's what I would look at first, granted that is a guess on my part.

I know that matlab ships with a compiler, runtime and a complete infrastructure...but I don't recall what version it uses.

Net net, probably not a simple solution...but what I would do if is run an MCR program without any ROS and investigate what shared libraries it loads. Do the same for a ROS application. Look particularly to see if different versions of the same-named shared libraries are being loaded. From that you can identify the offender. If that's the case, the fix...may be easy or not easy.

1) how old is your matlab? Might be that another newer version has updated C++ libraries and that may solve the problem. 2) you could recompile ros core libraries against the matlab headers and libraries. Alternatively, you could see if matlab might accept your ROS runtime libraries. Either way, there are risks.

But first things first...see what the respective environments are loading in terms of shared libraries and see if this is the issue at all. On windows one could use "dependency walker" to see what shared library dependencies exist for an application...on linux, not sure what'd be best. But certainly no shortage of utilities.

Good luck...these kinds of issues are very frustrating. I live with them daily as integrate ros in a number of different environments.

I have done some matlab integration with ROS, but not using the library compiler. Rather I have used the code generator for simulink which produces more or less raw C or C++ that integrates easily without dependencies. So I am not familiar with MCR or how that operates.

What it looks like(guess on my part), is that the Matlab shared C runtime libraries Matlab is using and loading at runtime differ from what your ros core libraries are compiled with. Maybe different versions. So when ROS is asking for this _ZN6... function that exists in the standard library it was compiled against, it is looking for it in the already loaded shared c library that matlab is using, but it isn't there.

This is a guess based on a quick google search I did of that function name that's missing, and the few folks that have similar problems (not with ROS but with other environments) seem to point in that direction. Anyway, that's what I would look at first, granted that is a guess on my part.

I know that matlab ships with a compiler, runtime and a complete infrastructure...but I don't recall what version it uses.

Net net, probably not a simple solution...but what I would do is run an MCR program without any ROS and investigate what shared libraries it loads. Do the same for a ROS application. Look particularly to see if different versions of the same-named shared libraries are being loaded. From that you can identify the offender. If that's the case, the fix...may be easy or not easy.

1) how old is your matlab? Might be that another newer version has updated C++ libraries and that may solve the problem. 2) you could recompile ros core libraries against the matlab headers and libraries. Alternatively, you could see if matlab might accept your ROS runtime libraries. Either way, there are risks.

But first things first...see what the respective environments are loading in terms of shared libraries and see if this is the issue at all. On windows one could use "dependency walker" to see what shared library dependencies exist for an application...on linux, not sure what'd be best. But certainly no shortage of utilities.

Good luck...these kinds of issues are very frustrating. I live with them daily as I integrate ros ROS in a number of different environments.