Catkin_make error building package on machine after image install

Hey all,

I am trying to build a package on the machine after I generated the image. I wanted to have it build with bitbake but had issues with external dependencies not building properly with BitBake so they have to be installed on the machine.

catkin_make fails with error:

-- Using CATKIN_DEVEL_PREFIX: /home/root/lidar_workspace/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/indigo
-- This workspace overlays: /opt/ros/indigo
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using default Python package layout
-- Could NOT find PY_em (missing:  PY_EM) 
CMake Error at /opt/ros/indigo/share/catkin/cmake/empy.cmake:29 (message):
  Unable to find either executable 'empy' or Python module 'em'...  try
  installing the package 'python-empy'
Call Stack (most recent call first):
  /opt/ros/indigo/share/catkin/cmake/all.cmake:145 (include)
  /opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:20 (include)
  CMakeLists.txt:52 (find_package)

running find tmp/sysroots/salvator-x/ -name "*empy*" results in:


I’m sure I’m missing something important related to installing python-empy but from what I can see with the recipes it should be installed with the packagegroup-ros-comm.

Any help is appreciated.

I know that @allenh1 recently ran into something similar here: you might want to follow up there.


Building further ROS packages on the target has not been implemented in meta-ros yet. These two issues point out the problems that some users had that tried it in the past:

Since then, no one has actually tried to do this, but we have been working on proper SDK support (nativesdk support in the bitbake tool chain), and the patches of this pull request below might help for your use case as well:

I actually just published my development branch of that pull request that I adjusted and rebased to the current master:

I did some minimal testing of that branch so far, but I don’t know if it resolves your use case.

Let us know if these patches already resolve the issue for you, or which further problem you encounter. I actually don’t know if building ROS packages on the target is easy to get working or involves a lot of patching of the catkin build tool.



@joek I fixed the empy issue by modiftying the PYTHONPATH exported in classes/ros.bbclass. You can see that change here.

@bulwahn, @allenh1,

Thank you for your replies. I will read into your suggestions further and let you know how it goes. I am currently working on a workaround to allow me to build the package using bitbake instead of on target. If it does not go well I will be swinging back to this method.

Thank you,

If this package you’re compiling has been released, there’s a good chance you can use superflore to generate the recipe. I’ve been working on automating the Open Embedded releases so they can parallel the Gentoo releases.

While things are not quite there, they are close. I’m not an expert, so any ideas as to what is blocking me would be great. You can find my current status on the issues for my fork of meta-ros.

The end package I am trying to build is not released. I am very much in the beginning of working with Open Embedded so I would not be of much help, but I am looking to get more involved in general. As for my progress, if it were not for the use of [OpenEXR v2.2.0|] and [OpenVDB v2.1.0 |] the package would build with less trouble. I did manage to get the workaround to work and the package built using BitBake. I will be investigating how to clean up the current build process, but for now this will do for the intended demo.

1 Like

Hello @joek,
I’m also facing the same problem, did you find any solution for this .

I have since left that employer so I don’t have access to the old codebase.

If memory serves, I had only hacky solutions, but I had to build a couple of those packages on my build machine separate and then wrote bitbake scripts to copy the files into the sysroots so that I could run catkin_make from bitbake instead of on the device after initial image creation.

Overall, I would not recommend the solution since it was very prone to failure, but I needed it for a demonstration and not a long term solution so it seemed to suffice.