When compiling pcl-ros, bitbake aborts because for compiling the
Crypto library in libpoco, it needs the openssl headers.
The condensed error output is
** Compiling src/CipherKeyImpl.cpp (debug, shared)
arm-oe-linux-gnueabi-g++ -march=armv5te -marm -mthumb-interwork
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
--sysroot=/home/lukas/oe-core/build/tmp-eglibc/sysroots/qemuarm
-I ... -DPOCO_BUILD_HOST=host -DPOCO_NO_WSTRING -DPOCO_UNBUNDLED
-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_REENTRANT -D_THREAD_SAFE
-DPOCO_NO_FPENVIRONMENT -g -D_DEBUG -fPIC -c src/CipherKeyImpl.cpp
-o ...
In file included from include/Poco/Crypto/CipherKeyImpl.h:44:0,
from include/Poco/Crypto/CipherKey.h:44,
from src/CipherKey.cpp:37:
include/Poco/Crypto/OpenSSLInitializer.h:45:33: fatal error: openssl/opensslconf.h: No such file or directory
#include <openssl/opensslconf.h>
^
compilation terminated.
In file included from include/Poco/Crypto/CipherKeyImpl.h:44:0,
from src/CipherKeyImpl.cpp:37:
include/Poco/Crypto/OpenSSLInitializer.h:45:33: fatal error: openssl/opensslconf.h: No such file or directory
#include <openssl/opensslconf.h>
^
compilation terminated.
make[1]: *** [.../tmp-eglibc/work/armv5te-oe-linux-gnueabi/libpoco/1.4.6p1-r0/poco-1.4.6p1-all/Crypto/obj/Linux/armv5te/debug_shared/CipherKey.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make -C /home/lukas/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libpoco/1.4.6p1-r0/poco-1.4.6p1-all/Util
make[1]: *** [.../tmp-eglibc/work/armv5te-oe-linux-gnueabi/libpoco/1.4.6p1-r0/poco-1.4.6p1-all/Crypto/obj/Linux/armv5te/debug_shared/CipherKeyImpl.o] Error 1
make[1]: Entering directory `/home/lukas/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libpoco/1.4.6p1-r0/poco-1.4.6p1-all/Util'
Before this commit, the following sequence of bitbake commands
failed because the path was set during compile time, and not at
runtime. After the patch from Dirk Thomas, the following sequence
now works.
bitbake nodelet-topic-tools -c cleansstate && \
bitbake dynamic-reconfigure && bitbake nodelet-topic-tools
This commit formats the libpoco recipe to follow the common
OpenEmbedded style more closely and removes a comment that points
to warnings that do not occur with the current recipe.
When updating from 1.9.41 to 1.9.47, the commit
c5dfa6305e
adds a routine in the CMakeLists.txt to find the pthread library.
This routine is not suitable for the use with our tool chain, i.e.,
it reports an error (cf. #125) when using roscpp-native.
This commit adds a patch that reverts that change in roscpp's
CMakeLists.txt.
In this commit, the angles directory is renamed to match repository
name in hydro/release.yaml, and a patch is required probably
because of the new catkin version.
To compile nodelet-topic-tools, we must provide a working
dynamic-reconfigure in the native sysroot. This requires
some adjustments to the native versions of the required
python modules.
In particular, the following tasks ran successfully for this
commit:
This command tests compiling rospack-native:
rm bitbake.lock cache/ sstate-cache/ tmp-eglibc/ -rf && bitbake rospack-native
This command tests compiling roslib-native:
rm bitbake.lock cache/ sstate-cache/ tmp-eglibc/ -rf && bitbake roslib-native
As nodelet-topic-tools uses rospack-native and roslib-native to
some extent (dependency: rospack-native -> roslib-native ->
dynamic-reconfigure-native -> nodelet-topic-tools), this command
tests running rospack-native and roslib-native:
rm bitbake.lock cache/ sstate-cache/ tmp-eglibc/ -rf && bitbake nodelet-topic-tools
This command tests compiling rospack and roslib:
rm bitbake.lock cache/ sstate-cache/ tmp-eglibc/ -rf && bitbake rospack
rm bitbake.lock cache/ sstate-cache/ tmp-eglibc/ -rf && bitbake roslib
All these command run with this commit without errors, and
future commits to these files should keep them run without
errors or justify modifications with better tests.
A minor open issue related to rospack is issue #116
(cf. https://github.com/bmwcarit/meta-ros/issues/116).
This commit incorporates feedback from Stefan Herbrechtsmeier.
The bitbake call before each build of a recipe was not required.
Commented out the fresh build, as it currently does not show more
problems than simply building in a shared environment.
Avoiding a fresh environment for each build decreases the runtime
of the test dramatically.
Lukas Bulwahn