Virtual-environments: Boost version is not the default one from the OS

Created on 3 Oct 2019  路  8Comments  路  Source: actions/virtual-environments

Describe the bug
I have an issue concerning the default version of Boost for instance provided with 16.04 and 18.04. Why to not use the one provided by the Ubuntu releases?

Virtual environments affected

  • [ ] macOS 10.14
  • [x] Ubuntu 16.04 LTS
  • [x] Ubuntu 18.04 LTS
  • [ ] Windows Server 2016 R2
  • [ ] Windows Server 2019
C++ bug

Most helpful comment

A workaround for this issue is to overwrite the BOOST_ROOT env variable to ensure that is not found by CMake, see for example in https://github.com/robotology/robotology-superbuild/pull/329 :
~
# Workaround for https://github.com/actions/virtual-environments/issues/10
- name: Avoid to use GitHub Actions-installed boost
shell: bash
run: |
echo "::set-env name=BOOST_ROOT::"
~

All 8 comments

From another user:

"As documented in https://help.github.com/en/articles/software-in-virtual-environments-for-github-actions#ubuntu-1804-lts, that image is not the Ubuntu Vanilla one, but it has been modified to contain the Boost 1.69 libraries, while the standard Ubuntu 18.04 image contains Boost 1.65 . The problem is that I need to use some dependencies contained in the Ulitibuntu repo that have been compiled against the system Boost 1.65, and they are not compatible with Boost 1.69 , see https://github.com/robotology/robotology-superbuild/issues/238 for more info.

I was wondering if there is any possibility of using the system's Boost 1.65 libraries with Ubuntu 18.04 on GitHub Actions, instead of the custom Boost 1.69."

Thanks @kaylangan for reporting my comment! With respect to when I wrote you the mail, something changes, as the failure reported in https://github.com/robotology/robotology-superbuild/issues/238 somehow is not present anymore, see https://github.com/robotology/robotology-superbuild/pull/241 .

I guess something changed again in these days, and we now experience the same error today.
The succesful runner was 2.163.1 / 20200102.1, while the one that is failing is 2.164 / 20200113.1.

See:

Error in the failed build:
~
2020-01-17T02:03:32.5842415Z CMake Error at /usr/local/share/cmake-3.12/Modules/FindBoost.cmake:2048 (message):
2020-01-17T02:03:32.5843151Z Unable to find the requested Boost libraries.
2020-01-17T02:03:32.5843210Z
2020-01-17T02:03:32.5843271Z Boost version: 1.69.0
2020-01-17T02:03:32.5843320Z
2020-01-17T02:03:32.5843386Z Boost include path: /usr/local/share/boost/1.69.0/include
2020-01-17T02:03:32.5843443Z
2020-01-17T02:03:32.5843518Z Could not find the following Boost libraries:
2020-01-17T02:03:32.5843558Z
2020-01-17T02:03:32.5843633Z boost_signals
2020-01-17T02:03:32.5843668Z
2020-01-17T02:03:32.5843743Z Some (but not all) of the required Boost libraries were found. You may
2020-01-17T02:03:32.5843840Z need to install these additional Boost libraries. Alternatively, set
2020-01-17T02:03:32.5843915Z BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
2020-01-17T02:03:32.5844022Z to the location of Boost.
~

Ok, I guess that the change is that in 2.163.1 / 20200102.1 BOOST_ROOT was defined, but was pointing to a non-existing directory (see the issue https://github.com/actions/virtual-environments/issues/83). Even if I not find the actual commit that fixed the issue, apparently the issue was fixed in 2.164 / 20200113.1, and this created again this problem.

A workaround for this issue is to overwrite the BOOST_ROOT env variable to ensure that is not found by CMake, see for example in https://github.com/robotology/robotology-superbuild/pull/329 :
~
# Workaround for https://github.com/actions/virtual-environments/issues/10
- name: Avoid to use GitHub Actions-installed boost
shell: bash
run: |
echo "::set-env name=BOOST_ROOT::"
~

Interestingly, the proposed workaround is able to fix some apparently unrelated failures in building a private project of ours:
~
[ 86%] Linking CXX executable ../../../bin/idjl_cartesian_motion_control_example
../../../lib/libidjl_motion_control_egm.so: undefined reference to abb::egm::EGMControllerInterface::ControllerMotion::WRITE_TIMEOUT_MS' ../../../lib/libidjl_motion_control_egm.so: undefined reference toabb::egm::EGMBaseInterface::WAIT_TIME_MS'
collect2: error: ld returned 1 exit status
~

Edit, it turns out that this problem was actually https://github.com/ros-industrial/abb_libegm/issues/67 , but it was triggered by the fact that some functions changed their signature in Boost 1.69 w.r.t. to Boost 1.65 .

As announced in https://github.com/actions/virtual-environments/issues/319#issue-554705142 , I guess this problem will be solved when BOOST_ROOT will not be defined anymore.

Hi @traversaro , @jcarpent ! Thanks for reporting this issue.
Yes, as announced in https://github.com/actions/virtual-environments/issues/319#issue-554705142 we are starting the process of $BOOST_ROOT variable deprecation, and it will be removed within 2 months.

Closing this issue for now. Feel free to open the new one if the problem occurs again.

Was this page helpful?
0 / 5 - 0 ratings