Error loading libkdl-transport-mqueue-gnulinux.so through docker when openGL is enabled

[orocos]

Error loading libkdl-transport-mqueue-gnulinux.so through docker when openGL is enabled

[meyerj]

Hmm, sounds strange. The symbol _ZNK3RTT4base18ChannelElementBase15isRemoteElementEv is defined in the core liborocos-rtt-gnulinux.so and should be already defined at the time the ComponentLoader loads the plugin. I do not see a relationship to OpenGL here, but I am not familiar with the Direct Rendering Manager.

Is the content of both containers really the same or could it be that due to some mount options you mixed different ABI-incompatible versions of RTT and the kdl_typekit plugin library? The symbol RTT::base::ChannelElementBase::isRemoteElement is present in master and toolchain-2.9 of RTT, but not in toolchain-2.8. So if you compiled RTT from source with one of the newer branches, you also have to compile all dependent typekit and component libraries from source against the same version. For the case you have a ROS installation on your system with ros-indigo-rtt installed (which is based on toolchain-2.8) and compile dependent packages from source, even against a newer version of RTT installed at some other location, you should uninstall ros-indigo-rtt or you cannot be sure that they pick up the older headers installed in /opt/ros/indigo/include alongside some other ROS dependencies.

We also used OpenGL in Docker containers in the past without any issues and without mounting /dev/dri (by providing the correct version of libGL.so only), but that was with the nvidia proprietary drivers and things might be different depending on the driver in use.