Crystal cross-compilation error

[alsora]

Hi,

I'm cross-compiling ROS2 Crystal and the build of this package fails.
Note that I have already built ROS2 Crystal from sources with no issues.

The error is:

--- stderr: tinyxml2_vendor
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find TinyXML2 (missing: TINYXML2_LIBRARY TINYXML2_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/FindTinyXML2.cmake:20 (find_package_handle_standard_args)
CMakeLists.txt:6 (find_package)

The problem is due to the changes that you did on 11 December commit 460faf8

If I revert to the previous commit (i.e. Bouncy release tag) it works fine.

I don't exactly understand what's going on with this package, but if there are some additional information that you need for debugging, just let me know.

[jacobperron]

Based on the error message:

Could NOT find TinyXML2 (missing: TINYXML2_LIBRARY TINYXML2_INCLUDE_DIR)

It would appear the issue is that the following lines are failing to find the tinyxml2 installation:

tinyxml2_vendor/cmake/Modules/FindTinyXML2.cmake

Lines 19 to 21 in 575ace5

	find_path(TINYXML2_INCLUDE_DIR NAMES tinyxml2.h)
	find_library(TINYXML2_LIBRARY tinyxml2)

Can you provide the platform you are compiling on and the version of TinyXML2 on your system?

[alsora]

I am cross-compiling ROS2 for an ARM v7 board.

On the board I have the following files:

./lib/libtinyxml2.so.7.0.1
./lib/libtinyxml2.so
./lib/libtinyxml2.so.7
./usr/include/tinyxml2.h

[nuclearsandwich]

I'm able to reproduce the error. One thing that tripped me up is that unlike our other vendor packages, tinyxml2_vendor has no provision for building and vendoring the target package so if tinyxml2 isn't found this package should probably fail to build with an error message.

In a Linux system without tinyxml2 installed at all, reverting 460faf8 allows the tinyxm2_vendor package to build successfully but there's still no tinyxml2 installed on the system, so building fastrtps on top of this workspace fails with:

--- stderr: fastrtps
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
/workspace/src/eProsima/Fast-RTPS/src/cpp/TINYXML2_INCLUDE_DIR
   used as include directory in directory /workspace/src/eProsima/Fast-RTPS/src/cpp
TINYXML2_LIBRARY (ADVANCED)
    linked by target "fastrtps" in directory /workspace/src/eProsima/Fast-RTPS/src/cpp

---

I'm not very practiced at cross-compilation with CMake and my reproduction of the issue is still native only.

Does your target sysroot contain pkg-config or CMake configuration files for tinyxml2? If not, that may be why the vendor package isn't finding your libraries. Fast-RTPS is doing things closer to what we were doing previously and the ultimate fix may wind up being a synthesis of both. I think there's something here and I'll investigate further.

[nuclearsandwich]

So in classic "I have investigated further and now I am even more confused" fashion... I have investigated further and now I am even more confused.

I have found some issues with the tinyxml2_vendor package.

Prior to #3 the casing of tinyxml2 in find_package_handle_standard_args(tinyxml2... and and the find module filename FindTinyXML2.cmake disagreed. This apparently prevents the failure to find the package from being a critical error.

Using version 0.4.0 of tinyxml2_vendor as a base in a container that doesn't have tinyxml2 installed here's the CMake output with two extra messages printed after find_package(TinyXML2 REQUIRED):

-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find tinyxml2 (missing: TINYXML2_LIBRARY TINYXML2_INCLUDE_DIR) 
-- TinyXML2_FOUND 0
-- TINYXML2_FOUND FALSE
-- Configuring done
-- Generating done
-- Build files have been written to: /workspace/build/tinyxml2_vendor

So due to that mismatch tinyxml2 isn't found but that's not treated as an error and the build proceeds. However checking TinyXML2_FOUND explicitly after the fact comes up as 0 and the uppercase TINYXML2_FOUND which is set as the upcased version of the package name tinyxml2 is explicitly set to FALSE.

Changing the name of the find module file to Findtinyxml2 and changing the CMakeLists.txt to find_package(tinyxml2 REQUIRED) is enough to also cause a failure but the desired fix is the one made in #3.

@alsora when you say reverting to Bouncy (0.4.0) "works fine", what exactly are you testing?

Can you share the CMake configuration output from both your Bouncy and Crystal builds? If you're using colcon it would be in the log file log/latest_build/tinyxml2_vendor/stdout_stderr.log. Thanks

[nuclearsandwich]

Could NOT find TinyXML2 (missing: TINYXML2_LIBRARY TINYXML2_INCLUDE_DIR)

From @alsora's original error message, the vendor package is finding neither the library file nor the include directory it's being told to look for.

[alsora]

Ok, I'm sorry, but I think that the behavior that I was seeing at the beginning was due to a mistake.

What I have is the following.

I'm trying to cross-compile the repositories contained in ros2.repos (both Bouncy and Crystal tags).
With Bouncy, there are no build errors even if tinyxml2 is not installed on my system. I have been using it for quite a lot and everything was working as expected.
With Crystal, if tinyxml2 is not installed on my system, the build fails.
The solution I got has been to use the toolchain to cross-compile from sources tinyxml2 and add it to the sysroot before cross-compiling.

What's interesting is that if, while compiling the ros2.repos Crystal tag, I revert this package to 0.4 the overall build of ros2.repos succeeds.
I don't understand why pluginlib (i.e. the only package that I'm compiling which depends on tinyxml2) doesn't complain about the missing library.

[nuclearsandwich]

I don't understand why pluginlib (i.e. the only package that I'm compiling which depends on tinyxml2) doesn't complain about the missing library.

Me either! Let's ask the maintainer of pluginlib... oh drat!

Are you building without Fast-RTPS? It also requires tinyxml2 although because it's not a "ROS" package it doesn't depend on tinyxml2_vendor. Their build is capable of bundling tinyxml2 but I don't believe they do so by default anymore.

With Crystal, if tinyxml2 is not installed on my system, the build fails.

In my opinion this is actually the desired behavior. The package that finds tinyxml2 should fail if it can't do so. The purpose of these vendor packages is to guarantee that the vendored project is available from somewhere.

[nuclearsandwich]

What's interesting is that if, while compiling the ros2.repos Crystal tag, I revert this package to 0.4 the overall build of ros2.repos succeeds.

Building pluginlib in a Crystal workspace without tinyxml2 and using tinyxml2_vendor from Bouncy workspace I get

--- stderr: pluginlib                            
CMake Error at /workspace/install/ament_cmake_target_dependencies/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:42 (message):
  ament_target_dependencies() the passed package name 'TinyXML2' was not
  found before
Call Stack (most recent call first):
  CMakeLists.txt:74 (ament_target_dependencies)
---

If I try to build more than just pluginlib I also get errors building Fast-RTPS (as expected without tinyxml2 installed).

[alsora]

I'm sorry, but for the next few days I will not be able to check again. I will repeat all the tests and give you some updates soon.

[nuclearsandwich]

I'm sorry, but for the next few days I will not be able to check again. I will repeat all the tests and give you some updates soon

🎄 No trouble. Happy Holidays! ⛄

[nuclearsandwich]

@alsora any news on this front or should we close this one out?

[alsora]

Sorry but I completely forgot about this.

Moreover, the issue is not present anymore, so either it has been fixed with the commits in January or I was doing some mistakes...