ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Pcl_ros with PCL 1.8 (ROS Lunar and newer) means linking to 139 VTK dynamic libraries


Compiling ROS from source I’ve noticed that PCL 1.8 (and thus pcl_ros) links to a newer version of the VTK library, which yields unbelievable 139 dynamic libraries to be linked to my programs. Crazy! According to , there is some performance penalty for every dynamically linked library.

Together with dependencies of the VTK libraries, we get to this number:

ldd /opt/ros/lunar/lib/ | wc -l

And all of that just to be able to transform a pointcloud (no visualizations etc).

I think pcl_ros should be refactored to two packages, one for “computing” and the other for visualizations. That could probably push the number of linked libraries much lower for computing-only uses of pcl_ros. Or it could be modularized even more… Not everybody needs surface reconstruction capabilities, for example.

What’s your opinion on this? Or is there some good reason to keep it all in one package?


Just for comparison:

ldd /usr/lib/blender/blender | wc -l

ldd `which meshlab` | wc -l


Splitting the visualisation parts out of PCL is certainly worth doing, in my opinion. PCL itself could also be modularised even more, but whether the return on that investment makes it worth doing is an open question.


PCL can be compiled without visualization, this removes the VTK dependency:


I would interested in what it takes to split this out. Currently I’ve been blocked compiling PCL from source, presumably from the large amount of dependencies. I’ve tried doubling memory and swap space (and of course on a fixed machine (laptop) with only 8GB of ram, it seems like 15GB isn’t even enough. Every time it runs out of memory, unfortunately that now means I have to change my workflow, and compile this on a much larger system, with substantially more RAM, when I have compiled quite large packages without much of an issue (i.e. opencv, kernels, etc.). I’ll try out disabling VTK to see if that helps move the process along, before investing in recompiling everything and setting up a new build machine.


Have you tried limiting the nr of concurrent jobs? The default is probably something like the nr of cpus/cores, which could easily lead to significant memory usage with C++ (templates, et al).


Absolutely, it was trying to compile gstreamer, and a kernel originally, but just compiling pcl by itself, consumes all memory even with running a single thread.