Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • master-next
  • v01.00.04
  • v01.00.03
  • v0.2
  • v0.2rc3
  • v0.2rc2
  • v0.2rc1
  • v0.1
  • v0.1rc2
  • v0.1rc1
11 results
Search by author
  • Any Author
  • Antoine Lima Antoine Lima limaanto
  • Arthur Detree Arthur Detree detreear
  • Guillaume Sanahuja Guillaume Sanahuja gsanahuj
3 authors
  1. Mar 19, 2017
  3. Feb 22, 2017
    • Dmitry Rozhkov's avatar
      kdl-parser: add explicit dependency on libeigen · d3d4634f
      Dmitry Rozhkov authored 
      
libeigen is an interface dependency needed by orocos-kdl and
orocos-kdl does export this dependency, but it does so with
a hardcoded absolute path pointing to the sysroot where
orocos-kdl was built. In case the sysroot doesn't exist
the compiler can't find libeigen's headers.

Unfortunately orocos-kdl's CMakeList.txt doesn't use
per-target include dirs, but global ones. I don't know
an easy way how to make them relocatable.

The easiest way to fix it is to add the explicit dependency
on libeigen to kdl-parser's CMakeList.txt. Anyway it's already
been declarated as a dependency in kdl-parser's recipe.

Signed-off-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      d3d4634f
    • Dmitry Rozhkov's avatar
      catkin: relocate dependency's headers to current sysroot · b0be1fc4
      Dmitry Rozhkov authored 
      If a package (A) depends on another package (B) and the package
B depends on Boost then it might happen that B produces BConfig.cmake
file where absolute paths to Boost's headers are put (because CMake's
standard FindBoost.cmake module reports absolute paths). In case of
Yocto it means that BConfig.cmake will contain something like
/path/to/build/tmp-glibc/work/i586/package_B/0.0.1/recipe-sysroot/usr/include.
The path may not exist at the moment when the package A is being built.
And that leads to the failure of the check this patch switches off.

The problem has been reported to catkin's issue tracker:
https://github.com/ros/catkin/issues/851



This patch "relocates" required headers from dependencies' sysroots
to the current sysroot by removing sysroot prefix from include dirs
in *Config.cmake files at the moment the files get created and
by prepending the include dirs again with the current sysroot prefix.

Signed-off-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      b0be1fc4
    • Dmitry Rozhkov's avatar
      catkin: avoid leaking host environment to sysroot when searching for libs · 2c1d47d0
      Dmitry Rozhkov authored 
      
Signed-off-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      2c1d47d0
  5. Feb 08, 2017
  7. Feb 02, 2017
  9. Feb 01, 2017
  11. Jan 28, 2017
    • Lukas Bulwahn's avatar
      pcl-conversions: also depend on cmake-modules · e98c5a50
      Lukas Bulwahn authored 
      
Without the dependency on cmake-modules, `bitbake pcl-conversions` can
possibly fail with:

```
| CMake Error at /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
|   Could not find a package configuration file provided by "cmake_modules"
|   with any of the following names:
|
|     cmake_modulesConfig.cmake
|     cmake_modules-config.cmake
|
|   Add the installation prefix of "cmake_modules" to CMAKE_PREFIX_PATH or set
|   "cmake_modules_DIR" to a directory containing one of the above files.  If
|   "cmake_modules" provides a separate development package or SDK, be sure it
|   has been installed.
| Call Stack (most recent call first):
|   CMakeLists.txt:4 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
```

The failure only occurs if cmake-modules has not been installed
before pcl-conversions is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`,
which builds many packages in parallel, did not
uncover this because cmake-modules was usually installed before
pcl-conversions was configured.

However, the issue is clearly reproducable with
`bitbake pcl-conversions cmake-modules -c cleanall && bitbake pcl-conversions`

The missing dependency was probably introduced by the automatic
recipe updates without checking for new dependencies.

Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      e98c5a50
    • Lukas Bulwahn's avatar
      eigen-conversions: also depend on cmake-modules · a14c2138
      Lukas Bulwahn authored 
      
Without the dependency on cmake-modules, `bitbake eigen-conversions`
can possibly fail with:

```
| CMake Error at /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/eigen-conversions/1.11.8-r0/recipe-sysroot-native/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
|   Could not find a package configuration file provided by "cmake_modules"
|   with any of the following names:
|
|     cmake_modulesConfig.cmake
|     cmake_modules-config.cmake
|
|   Add the installation prefix of "cmake_modules" to CMAKE_PREFIX_PATH or set
|   "cmake_modules_DIR" to a directory containing one of the above files.  If
|   "cmake_modules" provides a separate development package or SDK, be sure it
|   has been installed.
| Call Stack (most recent call first):
|   CMakeLists.txt:5 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
```

The failure only occurs if cmake-modules has not been installed
before eigen-conversions is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`, which
builds many packages in parallel, did not uncover this because
make-modules was usually installed before eigen-conversions was
configured.

However, the issue is clearly reproducible with
`bitbake eigen-conversions cmake-modules -c cleanall && bitbake eigen-conversions`

The missing dependency was probably introduced by the automatic
recipe updates without checking for new dependencies.

Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      a14c2138
    • Lukas Bulwahn's avatar
      eigen-stl-containers: depend on libeigen · 30d5e698
      Lukas Bulwahn authored 
      
Without the dependency on libeigen, `bitbake eigen-stl-containers`
can possibly fail with:

```
| CMake Error at CMakeLists.txt:8 (find_package):
|   By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
|   asked CMake to find a package configuration file provided by "Eigen3", but
|   CMake did not find one.
|
|   Could not find a package configuration file provided by "Eigen3" with any
|   of the following names:
|
|     Eigen3Config.cmake
|     eigen3-config.cmake
|
|   Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
|   "Eigen3_DIR" to a directory containing one of the above files.  If "Eigen3"
|   provides a separate development package or SDK, be sure it has been
|   installed.
|
|
| -- Configuring incomplete, errors occurred!
```

The failure only occurs if libeigen has not been installed
before eigen-stl-containers is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`,
which builds many packages in parallel, did not uncover this
because libeigen was usually installed before
eigen-stl-containers was configured.

However, the issue is clearly reproducible with
`bitbake eigen-stl-containers libeigen -c cleanall && bitbake eigen-stl-containers`

The missing dependency was probably overlooked in the creation of
the eigen-stl-containers recipe, i.e., in
commit a255e67c.

Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      30d5e698
  13. Jan 25, 2017
  15. Jan 10, 2017
    • Dmitry Rozhkov's avatar
      catkin: revert commit beb46774 · e3e990de
      Dmitry Rozhkov authored 
      The patch added in the reverted commit was meant to fix the issue
https://github.com/bmwcarit/meta-ros/issues/291



In fact it enables CMake to look for libraries in a host system which
leads to errors when a path is tested for a library presence with the
help of CMake's find_library() command: e.g. a non-existing host
directory is tested for library presence and find_library() returns
successfully because the library exists in bitbake's sysroot; then the
directory is used by the linker, but the library doesn't exist in the
directory -> failure. In worse cases the host directory may actually exist
and contain the library, but of wrong architecture, format or
incompatible ABI making finding the root cause a difficult task.

Signed-off-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      e3e990de
  17. Dec 15, 2016