Giter Club home page Giter Club logo

cross_compile's People

Contributors

artin-f avatar chriseichmann avatar christophebedard avatar dabonnie avatar darvg avatar deitry avatar dependabot-preview[bot] avatar dependabot[bot] avatar emersonknapp avatar filiperinaldi avatar hidmic avatar kjeremy avatar le5tes avatar lmayencourt avatar michaelorlov avatar olivier-haddad avatar snehaldb90 avatar stertingen avatar thomas-moulard avatar timple avatar tsc21 avatar zmichaels11 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cross_compile's Issues

Add Debian 9 host support to cross-compile cross_compile

Consolidated Issue (see initial report at the bottom)

The below behavior is observed when attempting to use the tool when the host is Debian 9.

This has been changed from a bug to a feature request to support that platform as a host platform for this tool.

python3-docker should be installed by pip instead of apt on Debian 9
Once this works, add Debian 9 support instructions to README.md

Testing

Manual QA: Verify cross-compile runs on Debian 9

Acceptance Criteria

  • Change python3-docker rosdep for Debian Buster to use pip
  • Create instructions in README.md for running on Debian Buster

Initial bug report: : pkg_resources.DistributionNotFound 'docker'

Hey people,
I am trying out the new toolchain on Debian Stretch but running into an issue:

$ ros2 run cross_compile cross_compile --sysroot-base-image raspbian/stretch --sysroot-path /path/to/sysroot/

Traceback (most recent call last):
  File "/home/xxx/ros2/install/cross_compile/lib/cross_compile/cross_compile", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/home/xxx/.local/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3251, in <module>
    @_call_aside
  File "/home/xxx/.local/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3235, in _call_aside
    f(*args, **kwargs)
  File "/home/xxx/.local/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3264, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/home/xxx/.local/lib/python3.5/site-packages/pkg_resources/__init__.py", line 583, in _build_master
    ws.require(__requires__)
  File "/home/xxx/.local/lib/python3.5/site-packages/pkg_resources/__init__.py", line 900, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/home/xxx/.local/lib/python3.5/site-packages/pkg_resources/__init__.py", line 786, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'docker' distribution was not found and is required by cross-compile

docker-ce is installed and runs without any problems. Might this be due to Debian Stretch python version?
Thanks!

Add steps following ros2 run command in README

Right now the README ends with executing

ros2 run cross_compile cross_compile ...

Add more details after that to explain:

  • What output is expected?
  • What does success/failure look like?
  • How to use the output of the script?

Support x86 targets

Description

This tool is handy for cross-compiling to non-native architectures, but it would also be useful in building for the same architecture as the host.

For example, this could be useful on a system that has no build tools installed. With docker and this package, a user could compile any ROS workspace in a single command.

Related Issues

Completion Criteria

  • A user on x86_64 can compile a workspace for their native architecture using this tool

Implementation Notes / Suggestions

This probably involves just adding a new target to the sysroot_compiler dictionaries, e.g. base image and toolchain. I don't foresee any complications.

Don't depend on ament Python linters via a ROS2 installation

Description

In order to remove this tool from the ROS2 build ecosystem, we can't depend on the ament linters via a ROS2 installation. Instead of relying on them that way, install via pip VCS option

Related Issues

Part of Epic #102

Completion Criteria

cross_compile does not depend on any ament packages being installed via apt

Implementation Notes/Suggestions

https://discourse.ros.org/t/ament-lint-for-pure-python-packages/12247/2 based on this conversation we should be able to just install the ament_lint packages with pip via its vcs options, e.g.

pip3 install -e "git+https://github.com/ament/[email protected]#egg=ament_lint&subdirectory=ament_lint" 

Pseudo-randomize container names to distinguish them from each other

Copied from the aws-ros-dev fork:


The script produces a docker image and starts a container with a fixed name. If the container is not stopped, all subsequent script executions will try to start the old container and produce incorrect results.

This can be mitigated by adding a fixed length random string at the end of the current container name, to distinguish between different invocations of the script.

Resources

Issue #27

New cross-compile workflow implementation

@ros2/aws-robotics is working on a proposed new design for the cross-compile workflow (ros2/design#233 and ros2/ros2#693) and we will be opening PRs in this repo for our changes.

@filiperinaldi would you be open to reviewing our PRs? If you or any other maintainer of this package would like to discuss the design, I can set up a meeting to talk about it.

Since this repo is not maintained by OSRF, would it be possible for members of our team to get write access to it in the future?

Allow user to skip rosdep collection

Description

As a time optimization in the build process, allow the user to skip collecting rosdeps. It can take about 10s to run rosdep update and when working on code without changing dependencies, it is not necessary every time.

This would be a "power-user feature"

Related Issues

Depends on #139

Completion Criteria

  • User can explicitly skip collecting rosdeps via a CLI flag
  • If the cc_internals/install_rosdeps.sh script doesn't exist already, raise an exception
  • Appropriate documentation exists on the flag to warn about the problems it can cause when used incorrectly. Something like "NOTE: This is an optimization feature for incremental builds to save time running rosdep update - you must have run without this flag at least once to collect the initial dependencies. It has undefined behavior if you change the dependencies of your workspace."

Implementation Notes / Suggestions

Just need a bool CLI flag to pass to the cross_compile pipeline and put the rosdep step in an if-block

Testing Notes / Suggestions

Add a unit test!

Make cross_compile a pure Python package instead of ROS 2 package

Now that cross_compile has ROS 1 support, it needs to be usable from all supported ROS distributions. Right now it is a ROS 2 package, which means it cannot be released into ROS Kinetic and Melodic as is.

It is desirable to convert it to a python package and release it through pip so that it is independent of ROS completely and installation steps are uniform independent of ROS distro used.

ros2: command not found

Hi everyone.

My OS is ubuntu 16.04.

I have successfully cross compile by using:
colcon build --packages-up-to cross_compile

and I have successfully source the local_setup.sh by using:
source install/local_setup.sh

However, when I Copy the QEMU Binaries and Copy the ROS2 packages, I have problems on

pibotvm@ubuntu:~$ ros2 run cross_compile cross_compile --arch aarch64 --os ubuntu --sysroot-path /home/pibotvm/sysroot/
ros2: command not found

May is there anything wrong?

Bad formatting on compilation failure

Description

When the cross compile build step fails, the raised exception contains all output lines concatenated by \n. It makes it very hard to read the compiler error!

Expected Behavior

The colcon output is well-formatted on failure.

Actual Behavior

A docker.exceptions.ContainerError is raised with a single string, which is printed out as a single line.

To Reproduce

Add a syntax error to dummy_pkg_ros2 and build

System (please complete the following information)

  • OS: Ubuntu Bionic
  • ROS 2 Distro: Dashing

Additional context

This should be fairly simple to solve, I think we just need to catch the exception and process the output properly, perhaps via output.split('\n')

Release package as debs for Debian/Ubuntu installation

Description

Other Python packages in the ROS ecosystem are available both via pip and apt, e.g. colcon. Follow their lead and release this package into .debs also.

Related Issues

N/A

Completion Criteria

A user can apt install ros-cross-compile from the OpenRobotics apt repositories.

Implementation Notes / Suggestions

Follow the instructions https://github.com/ros-infrastructure/ros_release_python here to verify packaging, and send request to OSRF to add the package to the build farm for upload.

Testing Notes / Suggestions

Generate the deb locally and try installing it into a fresh environment. Perhaps use rocker since it allows for docker-from-docker running.

Fix installation instructions

Feedback from #35

  • There is no remark in README that Dockerfile_workspace should be putted into sysroot folder. If this is correct, I guess it should be stated here: https://github.com/ros-tooling/cross_compile#3-run-the-cross-compilation-script . At least I couldn't get it to work until I put it there.

  • Connected to this - maybe it should be stated explicitely that argument --sysroot-path must be absolute path; that took some time to realise why sysroot/Dockerfile_workspace was not found.

Two README command issues

Description

Went through the README to cross compile a project and found two issues with the copy + paste commands. The first is the command:

cp -r <full_path_to_your_ros_ws>/src sysroot/ros_ws/src

Ends up making the path:

sysroot/ros_ws/src/src/<ros_package>

Need to remove the last src there.

Second is when running:

python3 -m ros_cross_compile \
  --sysroot-path /absolute/path/to/sysroot \
  --arch aarch64 \
  --os ubuntu
  --rosdistro dashing

with /sysroot on the end, it complains that it can't find sysroot inside sysroot. Full exception:

admin:~ $ python3 -m ros_cross_compile --sysroot-path ~/environment/sysroot/ --arch aarch64 --os ubuntu --rosdistro dashing
/usr/lib/python3/dist-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.25.7) or chardet (3.0.4) doesn't match a supported version!
  RequestsDependencyWarning)
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/ros_cross_compile/__main__.py", line 21, in <module>
    sys.exit(_main())
  File "/home/ubuntu/.local/lib/python3.6/site-packages/ros_cross_compile/ros_cross_compile.py", line 137, in main
    custom_data_dir=args.custom_data_dir)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/ros_cross_compile/sysroot_compiler.py", line 257, in __init__
    self._setup_sysroot_dir(custom_setup_script_path, custom_data_dir)
  File "/home/ubuntu/.local/lib/python3.6/site-packages/ros_cross_compile/sysroot_compiler.py", line 278, in _setup_sysroot_dir
    sysroot_dir=self._target_sysroot))
FileNotFoundError: Sysroot directory not found at "/home/ubuntu/environment/sysroot/sysroot". Make sure you specify the full path to the directory containing "sysroot".

Log a warning when an unsupported version of Python is used.

Running cross_compile with Python <3.6 should log a warning.

We should not prevent users from using unsupported versions, to avoid needlessly blocking users from using Python versions which just "happen to work", but users should be warned that we are not supporting the version they are using.

rcl package fails cross compilation

I am trying to cross compile ROS2 for arm on Debian Stretch.
Following the official instructions I am able to start compilation until, however it gets terminated reaching rcl package:

Starting >>> rcl
Starting >>> rosidl_runtime_py
Finished <<< rosidl_runtime_py [1.05s]                                                               
--- stderr: rcl                                                                                      
CMake Warning:
  Manually-specified variables were not used by the project:

    SECURITY


/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: warning: librosidl_typesupport_fastrtps_c.so, needed by /root/cc_ws/ros2_ws/install/lib/librmw_fastrtps_dynamic_cpp.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: warning: librosidl_typesupport_fastrtps_cpp.so, needed by /root/cc_ws/ros2_ws/install/lib/librmw_fastrtps_dynamic_cpp.so, not found (try using -rpath or -rpath-link)
/root/cc_ws/ros2_ws/install/lib/librmw_fastrtps_dynamic_cpp.so: undefined reference to `rosidl_typesupport_fastrtps_cpp::wstring_to_u16string(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::__cxx11::basic_string<char16_t, std::char_traits<char16_t>, std::allocator<char16_t> >&)'
/root/cc_ws/ros2_ws/install/lib/librmw_fastrtps_dynamic_cpp.so: undefined reference to `rosidl_typesupport_fastrtps_c::wstring_to_u16string(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, rosidl_generator_c__U16String&)'
/root/cc_ws/ros2_ws/install/lib/librmw_fastrtps_dynamic_cpp.so: undefined reference to `rosidl_typesupport_fastrtps_c::u16string_to_wstring(rosidl_generator_c__U16String const&, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&)'
/root/cc_ws/ros2_ws/install/lib/librmw_fastrtps_dynamic_cpp.so: undefined reference to `rosidl_typesupport_fastrtps_cpp::u16string_to_wstring(std::__cxx11::basic_string<char16_t, std::char_traits<char16_t>, std::allocator<char16_t> > const&, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&)'
collect2: error: ld returned 1 exit status
make[2]: *** [test/service_fixture__rmw_fastrtps_dynamic_cpp] Error 1
make[1]: *** [test/CMakeFiles/service_fixture__rmw_fastrtps_dynamic_cpp.dir/all] Error 2
make: *** [all] Error 2
---
Failed   <<< rcl	[ Exited with code 2 ]
--- stderr: geometry_msgs                                                          
CMake Warning:
  Manually-specified variables were not used by the project:

    SECURITY


---
Aborted  <<< geometry_msgs

Summary: 133 packages finished [12min 51s]
  1 package failed: rcl
  1 package aborted: geometry_msgs
  113 packages had stderr output: action_msgs actionlib_msgs ament_cmake ament_cmake_auto ament_cmake_clang_format ament_cmake_copyright ament_cmake_core ament_cmake_cppcheck ament_cmake_cpplint ament_cmake_export_definitions ament_cmake_export_dependencies ament_cmake_export_include_directories ament_cmake_export_interfaces ament_cmake_export_libraries ament_cmake_export_link_flags ament_cmake_flake8 ament_cmake_gmock ament_cmake_gtest ament_cmake_include_directories ament_cmake_libraries ament_cmake_lint_cmake ament_cmake_nose ament_cmake_pclint ament_cmake_pep257 ament_cmake_pep8 ament_cmake_pyflakes ament_cmake_pytest ament_cmake_python ament_cmake_ros ament_cmake_target_dependencies ament_cmake_test ament_cmake_uncrustify ament_cmake_xmllint ament_index_cpp ament_lint_auto ament_lint_common builtin_interfaces class_loader composition_interfaces connext_cmake_module console_bridge_vendor example_interfaces fastcdr fastrtps_cmake_module geometry_msgs gmock_vendor gtest_vendor kdl_parser launch_testing_ament_cmake libcurl_vendor libyaml_vendor lifecycle_msgs opensplice_cmake_module orocos_kdl osrf_testing_tools_cpp pendulum_msgs pluginlib poco_vendor python_cmake_module rcl rcl_interfaces rcl_logging_log4cxx rcl_logging_noop rcpputils rcutils resource_retriever rmw rmw_connext_cpp rmw_connext_shared_cpp rmw_implementation rmw_implementation_cmake rmw_opensplice_cpp ros_environment rosgraph_msgs rosidl_adapter rosidl_cmake rosidl_default_generators rosidl_default_runtime rosidl_generator_c rosidl_generator_cpp rosidl_generator_dds_idl rosidl_generator_py rosidl_parser rosidl_typesupport_c rosidl_typesupport_connext_c rosidl_typesupport_connext_cpp rosidl_typesupport_cpp rosidl_typesupport_fastrtps_c rosidl_typesupport_fastrtps_cpp rosidl_typesupport_interface rosidl_typesupport_introspection_c rosidl_typesupport_introspection_cpp rosidl_typesupport_opensplice_c rosidl_typesupport_opensplice_cpp rttest shared_queues_vendor sqlite3_vendor std_msgs std_srvs test_interface_files test_launch_testing test_msgs test_osrf_testing_tools_cpp tinydir_vendor tinyxml2_vendor tinyxml_vendor tlsf uncrustify_vendor unique_identifier_msgs urdf urdfdom urdfdom_headers yaml_cpp_vendor
  95 packages not processed

It seems like librosidl_typesupport_fastrtps_c is not found.

Any idea on this? Or should I just try an Ubuntu VM?
Thanks!

Only install dependencies and build up to a specific package

Description

Often when building a workspace for a target device, I don't care about many package in a workspace (such as visualization tools), but those packages are included in the same repositories as libraries I do need. Because of this, rosdep and colcon build for my workspace includes a lot that I don't need, which makes it take longer and produces bigger results.

Related Issues

N/A

Completion Criteria

  • I can specify what package is the entrypoint for my application, and the cross compile tool will only install the corresponding dependencies, and build up to that package.

Implementation Notes / Suggestions

  • Use colcon list -p --packages-up-to $PACKAGE to determine the exact list of paths for dependencies, and pass that to rosdep install --from-paths, to get the dependency subset
  • Pass --packages-up-to to colcon build in the build step

Testing Notes / Suggestions

  • Create a dummy workspace with 2 packages, specify the "up-to" option, and see that the produced install directory only has one package in it.

Perform an incremental build on target workspace (instead of full rebuild)

Description

When running cross_compile, if there are any source changes, the entire workspace is rebuilt from scratch, rather than only building changed things, as in a standard colcon build workflow.

Depends on #164

Completion Criteria

  • If only one package in a workspace has been changed, only that package (and upstream dependents) are rebuilt

Implementation Notes

This most likely entails

  • exporting the build directory alongside the install directory for the cross-compiled build
  • mounting or copying both build and install into the build environment directly before building so that cache checks find them

Add supported cross compile targets to README

Description

Supported target platforms should be easily located in the README doc so users of Cross Compile can quickly know what is supported.

Test Plan

  • N/A

Documentation

  • Update README.md to display supported cross compile targets

Release Plan

  • check in PR

Acceptance Criteria

  • README.md is updated
  • Release plan has been completed

Once all above items are checked, this story can be moved to done.

Resources

docker build fails due to rosdep issue

Hi,

I was following the guide located here for cross-compiling and the command:

~$ docker build -t arm_ros2:latest -f ros2_ws/src/cross_compile/sysroot/Dockerfile_ubuntu_arm .

fails due on step 20/23 because of the following error:

ERROR: the following packages/stacks could not have their rosdep keys resolvedto system dependencies:
examples_rclcpp_minimal_composition: Cannot locate rosdep definition for ...

I was able to fix this and build properly by changing line 75 from sysroot/Dockerfile_ubuntu_arm:

RUN rosdep install --from-paths src \
    --ignore-src \
    --rosdistro crystal -y \
    --skip-keys "console_bridge \
        fastcdr \
        fastrtps \
        libopensplice67 \
        libopensplice69 \
        rti-connext-dds-5.3.1 \
        urdfdom_headers"

to this

RUN rosdep install --from-paths src \
    --ignore-src \
    --rosdistro dashing -y \
    --skip-keys "console_bridge \
        fastcdr \
        fastrtps \
        libopensplice67 \
        libopensplice69 \
        rti-connext-dds-5.3.1 \
        urdfdom_headers"

It seems that there is an issue with the crystal repositories didn't have specific packages, but the dashing one does. Hope this helps!

Use cross-compilers to compile workspace instead of an emulated compilation

Description

Currently, the tool performs the source build inside a QEMU-emulated container for the target architecture.

The desired control flow is:

  • create the target architecture sysroot by running rosdep in an emulated image
  • use that generated sysroot in a native environment with a cross-compiler

This will give better performance by compiling natively, and should allow for more flexible usage, to let users supply their own sysroots or compiler toolchains.

Test Plan

  • No failures in existing testing
  • Unit tests for new/untested parts of code
  • Changes to the e2e test as required by new workflow

Documentation Plan

  • Update README setup and installation instructions
  • Specify the supported target architectures and platforms
  • Have instructions to install the correct cross compilers in the Setup steps in README

Release Plan

  • Changes should be merged in master

Acceptance Criteria

  • Code has been implemented, reviewed and merged.
  • Test plan has been completed
  • Release plan has been completed

Once all above items are checked, this story can be moved to done.

Resources

None

Provide base Docker images for download instead of building locally

Description

On first use, building the rosdep collector and sysroot images take a long time (especially sysroot, since it's emulated). It would be nice to provide the undifferentiated portion of the build (e.g. rosdep, build tools) as a downloadable docker image, which should save a lot of time for the average case.

Related Issues

N/A

Completion Criteria

  • Provide the following docker images in a Docker registry
    • rosdep - x86_64 only for all target operating systems
      • Ubuntu, Debian
      • comes out to 2 images
    • build tools - for the matrix of target architectures, OS, and ros versions
      • ros, ros2
      • Ubuntu, Debian
      • aarch64, armhf
      • comes out to 8 images
    • This is 10 total images to be hosted on a registry to cover the most common use cases
  • When the needed image cannot be found,

Implementation Notes / Suggestions

Testing Notes / Suggestions

Run an additional nightly e2e test build, configured to be able to find the GitHub Package artifacts

Expand documentation on what's needed after the base image is built

Description

We need to have a tutorial in the README explaining how to take a sample repo and compile it using the tool

Test Plan

  • Check that the doc instructions are actually working
  • Evaluate if an e2e test could validate automatically

Documentation Plan

  • README.md update

Release Plan

  • Merge into master

Acceptance Criteria

  • Test plan has been completed
  • Release plan has been completed

Once all above items are checked, this story can be moved to done.

cross_compile problem on sysroot_compile.py

Hello, everyone! Sorry to bother you. I have one question when I cross compile ros2.

when I Install prerequisites and Installing from source. However, when I do

colcon build --packages-up-to cross_compile,

Here come a problem,

Starting >>> cross_compile
--- stderr: cross_compile
File "/home/pibotvm/ros2_cross_compile_ws/install/cross_compile/lib/python3.5/site-packages/cross_compile/sysroot_compiler.py", line 84
SYSROOT_DIR_NAME: str = 'sysroot'
^
SyntaxError: invalid syntax


Finished <<< cross_compile [3.32s]

Does anyone know how to solve this problem?

THX.

Allow user to specify colcon defaults file

Description

In my robot application, I build one entrypoint package for the robot-side runtime (which is headless), and a different one for the development computer that I use to visualize and send commands.

However, with the ability to run x86 builds now, I can invoke two variations of this tool to create a docker runtime image and build those packages.

Right now, I have to change the defaults.yaml file in my workplace in between builds. Instead it would be nice to specify this via the commandline.

ros_cross_compile --colcon-defaults something.yaml, if the user doesn't specify then use defaults.yaml

Related Issues

N/A

Completion Criteria

  • User can expicitly specify the relative path of the colcon defaults yaml file within their workspace.

Implementation Notes / Suggestions

  • Add command line option
  • pass it to docker client constructor, use that or default value on None

Testing Notes / Suggestions

Add dependencies test with a non-default-named defaults file and make sure it is honored in the colcon list

Cross compile issues with own compiler toolchains and sysroot

I want to cross compile ros2 to Hi3559 platform with the compiler toolchains and sysroot that Hisi provide. This is the detail : ros2/rclcpp#957 (comment)

I cross compiled the deps apr, apr-util, log4cxx, tinyxml, tinyxml2, poco, openssl, python3.6 in advance and install them to the target filesystem.

Here is the TOOLCHAIN file.
TOOLCHAIN_FILE

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)

set(HISI_ROOT "/opt/hisi-linux/x86-arm/aarch64-himix100-linux")
set(CMAKE_C_COMPILER "${HISI_ROOT}/bin/aarch64-himix100-linux-gcc")
set(CMAKE_CXX_COMPILER "${HISI_ROOT}/bin/aarch64-himix100-linux-g++")

# This is the target sysroot
set(CMAKE_SYSROOT "${HISI_ROOT}/target")

set(CMAKE_FIND_ROOT_PATH
    # This is where I install ros2
    /home/r18119/ros_hisi/dashing/install
    # This is where I cross compiled deps install
    /home/r18119/hisi_target
)

MESSAGE(STATUS ${CMAKE_FIND_ROOT_PATH})

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

# This assumes that pthread will be available on the target system
    # (this emulates that the return of the TRY_RUN is a return code "0"
set(THREADS_PTHREAD_ARG "0"
      CACHE STRING "Result from TRY_RUN" FORCE)

There are two problems when cross compiling tf2_ros and rclcpp_components package, which I think can be sorted to one kind.

The following are err logs:
tf2_ros

--- stderr: tf2_ros                                                                                                               
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: librosidl_typesupport_fastrtps_cpp.so, needed by /home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: librosidl_typesupport_fastrtps_c.so, needed by /home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libfastrtps.so.1, needed by /home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libssl.so.3, needed by /home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libcrypto.so.3, needed by /home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libfastcdr.so.1, needed by /home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libPocoFoundation.so.64, needed by /home/r18119/ros_hisi/dashing/install/lib/librosidl_typesupport_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libyaml.so, needed by /home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so, not found (try using -rpath or -rpath-link)
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(char&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(short&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `eprosima::fastcdr::Cdr::serializeBoolSequence(std::vector<bool, std::allocator<bool> > const&)'
/home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `rosidl_typesupport_fastrtps_c__identifier'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(double)'
/home/r18119/ros_hisi/dashing/install/lib/librosidl_typesupport_c.so: undefined reference to `Poco::SharedLibrary::hasSymbol(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(float*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(int*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `eprosima::fastcdr::Cdr::state::state(eprosima::fastcdr::Cdr const&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(char*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_parser_delete'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(bool const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(double*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_parser_set_input_file'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(long const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_event_delete'
/home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(int)'
/home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(int&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(short*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_parser_parse'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(long&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeBoolSequence(std::vector<bool, std::allocator<bool> >&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `eprosima::fastcdr::Cdr::setState(eprosima::fastcdr::Cdr::state&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(long)'
/home/r18119/ros_hisi/dashing/install/lib/libbuiltin_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `rosidl_typesupport_fastrtps_cpp::typesupport_identifier'
/home/r18119/ros_hisi/dashing/install/lib/librmw_implementation.so: undefined reference to `Poco::SharedLibrary::getPath[abi:cxx11]() const'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(float&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(long*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(double const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librosidl_typesupport_c.so: undefined reference to `Poco::SharedLibrary::getSymbol(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(int const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `typeinfo for eprosima::fastcdr::exception::Exception'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_parser_initialize'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(float)'
/home/r18119/ros_hisi/dashing/install/lib/librmw_implementation.so: undefined reference to `Poco::Exception::displayText[abi:cxx11]() const'
/home/r18119/ros_hisi/dashing/install/lib/librmw_implementation.so: undefined reference to `typeinfo for Poco::LibraryLoadException'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::readString(unsigned int&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(float const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(char const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(bool)'
/home/r18119/ros_hisi/dashing/install/lib/librosidl_typesupport_c.so: undefined reference to `Poco::SharedLibrary::SharedLibrary(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(double&)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(char const*)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(short)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(char)'
/home/r18119/ros_hisi/dashing/install/lib/libstd_msgs__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(short const*, unsigned long)'
collect2: error: ld returned 1 exit status
make[2]: *** [static_transform_publisher] Error 1
make[1]: *** [CMakeFiles/static_transform_publisher.dir/all] Error 2
make: *** [all] Error 2

rclcpp_components

--- stderr: rclcpp_components                                                                                      
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: librosidl_typesupport_fastrtps_cpp.so, needed by /home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: librosidl_typesupport_fastrtps_c.so, needed by /home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libfastrtps.so.1, needed by /home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libssl.so.3, needed by /home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libcrypto.so.3, needed by /home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libfastcdr.so.1, needed by /home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so, not found (try using -rpath or -rpath-link)
/opt/hisi-linux/x86-arm/aarch64-himix100-linux/host_bin/../lib/gcc/aarch64-linux-gnu/6.3.0/../../../../aarch64-linux-gnu/bin/ld: warning: libyaml.so, needed by /home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so, not found (try using -rpath or -rpath-link)
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(char&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `eprosima::fastcdr::Cdr::serializeBoolSequence(std::vector<bool, std::allocator<bool> > const&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `rosidl_typesupport_fastrtps_c__identifier'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(double)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `eprosima::fastcdr::Cdr::state::state(eprosima::fastcdr::Cdr const&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(char*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_parser_delete'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(bool const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(double*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_parser_set_input_file'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(long const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_event_delete'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(int)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(int&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_parser_parse'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(long&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeBoolSequence(std::vector<bool, std::allocator<bool> >&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `eprosima::fastcdr::Cdr::setState(eprosima::fastcdr::Cdr::state&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `rosidl_typesupport_fastrtps_cpp::typesupport_identifier'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserializeArray(long*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(double const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_cpp.so: undefined reference to `typeinfo for eprosima::fastcdr::exception::Exception'
/home/r18119/ros_hisi/dashing/install/lib/librcl_yaml_param_parser.so: undefined reference to `yaml_parser_initialize'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::readString(unsigned int&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serializeArray(char const*, unsigned long)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(bool)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::deserialize(double&)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(char const*)'
/home/r18119/ros_hisi/dashing/install/lib/librcl_interfaces__rosidl_typesupport_fastrtps_c.so: undefined reference to `eprosima::fastcdr::Cdr::serialize(char)'
collect2: error: ld returned 1 exit status
make[2]: *** [component_container_mt] Error 1
make[1]: *** [CMakeFiles/component_container_mt.dir/all] Error 2
make: *** [all] Error 2
---

It seems like that it can not find the libraries depend on when building librcl_interfaces__*.so, so I add 'rpath' to cmake toolchain file , but it still doesn't work.

# /home/r18119/ros_hisi/dashing/install is where I install ros2
add_compile_options(-L/home/r18119/ros_hisi/dashing/install/lib -Wl,-rpath=/home/r18119/ros_hisi/dashing/install)

Debian build fail.

Hi,
I'm trying to cross-compile ROS2 for the RPI3 but it fail when is installling the ROS2 dependencies. This is the log:

 ros2 run cross_compile cross_compile --sysroot-path ~/ros2_cc_pck  -a armhf -o debian
INFO:cross_compile.sysroot_compiler:Checking sysroot directory... foo
INFO:cross_compile.sysroot_compiler:Fetching sysroot base image: arm32v7/debian:latest
INFO:cross_compile.sysroot_compiler:Building workspace image: juan/armhf-debian-fastrtps-dashing:latest
INFO:cross_compile.sysroot_compiler:Step 1/29 : ARG ROS2_BASE_IMG
INFO:cross_compile.sysroot_compiler:Step 2/29 : FROM ${ROS2_BASE_IMG}
INFO:cross_compile.sysroot_compiler:---> b6efee0ab4f5
INFO:cross_compile.sysroot_compiler:Step 3/29 : ARG ROS2_WORKSPACE
INFO:cross_compile.sysroot_compiler:---> Using cache
INFO:cross_compile.sysroot_compiler:---> b4d6b4fe6f8a
INFO:cross_compile.sysroot_compiler:Step 4/29 : ARG ROS_DISTRO
INFO:cross_compile.sysroot_compiler:---> Using cache
INFO:cross_compile.sysroot_compiler:---> 1c504fef1e15
INFO:cross_compile.sysroot_compiler:Step 5/29 : ARG TARGET_TRIPLE
INFO:cross_compile.sysroot_compiler:---> Using cache
INFO:cross_compile.sysroot_compiler:---> 79d35faa8a1e
INFO:cross_compile.sysroot_compiler:Step 6/29 : ARG TARGET_ARCH
INFO:cross_compile.sysroot_compiler:---> Using cache
INFO:cross_compile.sysroot_compiler:---> e153e7b67843
INFO:cross_compile.sysroot_compiler:Step 7/29 : COPY qemu-user-static/ /usr/bin/
INFO:cross_compile.sysroot_compiler:---> Using cache
INFO:cross_compile.sysroot_compiler:---> eb6cd45fd965
INFO:cross_compile.sysroot_compiler:Step 8/29 : RUN echo 'Etc/UTC' > /etc/timezone &&     ln -sf /usr/share/zoneinfo/Etc/UTC /etc/localtime
INFO:cross_compile.sysroot_compiler:---> Using cache
INFO:cross_compile.sysroot_compiler:---> 4c9649feeeaf
INFO:cross_compile.sysroot_compiler:Step 9/29 : RUN apt-get update && apt-get install -y         tzdata         locales     && rm -rf /var/lib/apt/lists/*
INFO:cross_compile.sysroot_compiler:---> Using cache
INFO:cross_compile.sysroot_compiler:---> 42ab1e05224f
INFO:cross_compile.sysroot_compiler:Step 10/29 : RUN locale-gen en_US en_US.UTF-8 &&     update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
INFO:cross_compile.sysroot_compiler:---> Running in 8378b349d6e7
INFO:cross_compile.sysroot_compiler:Generating locales (this might take a while)...
INFO:cross_compile.sysroot_compiler:Generation complete.
INFO:cross_compile.sysroot_compiler:*** update-locale: Error: invalid locale settings:  LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8

ERROR:cross_compile.sysroot_compiler:Error building sysroot image. The following error was caught:
The command '/bin/sh -c locale-gen en_US en_US.UTF-8 &&     update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8' returned a non-zero code: 255
NoneType: None
ERROR:cross_compile.sysroot_compiler:BuildError does not take keyword arguments
Traceback (most recent call last):
  File "/home/juan/ros2_cc_pck/install/cross_compile/lib/python3.6/site-packages/cross_compile/sysroot_compiler.py", line 287, in execute_cc_pipeline
    self.build_workspace_sysroot_image()
  File "/home/juan/ros2_cc_pck/install/cross_compile/lib/python3.6/site-packages/cross_compile/sysroot_compiler.py", line 251, in build_workspace_sysroot_image
    raise docker.errors.BuildError(reason=error_line, build_log=error_line)
TypeError: BuildError does not take keyword arguments
INFO:cross_compile.ros2_cross_compile:To setup the cross compilation build environment:
1. Run the command below to setup using sysroot's GLIBC for cross-compilation.
`bash .`
2. Run the command below to export the environment variables used by the cross-compiled ROS packages.
`source .`'

If I execute locate inside of the docker, it returns that is POSIX instead of UTF-8, I don't know if this might be the problem.

I'm working with Ubuntu 18.04.

Build outputs are not `chown`ed to the current user if build fails

Description

At the end of cross-compilation, the build and install directory are chowned to the invoking user (build step is run as root in the container). However, if the build fails, this step isn't run

Expected Behavior

After the build is done, I can easily modify or remove build and install outputs.

Actual Behavior

If the build fails, the ownership of the files is not changed. This shows up as an error failing to remove the /tmp outputs in the run_e2e_test.sh script, if the build fails.

To Reproduce

  • Add a C++ syntax error to dummy_pkg_ros
  • Run run_e2e_test.sh

System (please complete the following information)

  • OS: Ubuntu Bionic
  • ROS 2 Distro: Dashing

Additional context

This should be solvable with an exit hook in the build_workspace.sh script

Integrate GitHub Action for pure python package to build and test on OS matrix

Description

Instead of using our custom ROS2 CI GH Actions, set up this repo to use a CI Action for regular python packages.

Related Issues

Part of Epic #102
Depends on #109

Completion Criteria

  • PRs are built with python action
  • PRs are tested with python action
  • Artifact of the build can be used in local virtualenv

Implementation Notes/Suggestions

https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/

Combine rosdep multiple apt commands into a single apt command

Description

On a sizeable ros project, there may be a few dozen rosdeps to install. The script that rosdep output has one apt-get install -y command per dependency. Every apt install command takes time to read the package list, especially in an emulated environment this takes several seconds. When the given installation command was a no-op, which often happens as many ros packages share dependencies, this time is completely wasted.

A manipulation of the output script to combine into a single apt-get install -y pkg pkg pkg command will speed up this step significantly.

Related Issues

N/A

Completion Criteria

  • install_rosdeps.sh script output of gather_rosdeps phase has all apt-get commands combined into one.

Implementation Notes / Suggestions

something like

cat install_rosdeps.sh |
# match `apt-get install` lines
sed some_pattern |
# get just the package names 
awk '{print $4}' |
# maybe sort?
sort |
# combine onto one line
awk '{print}' ORS='" '

Testing Notes / Suggestions

Check file contents to expected.

Enable colcon defaults file to customize list/build

Description

It should be possible now to customize the colcon build with arbitrary arguments such as --packages-up-to by providing a colcon defaults file.

If the user can easily provide this, then we can avoid having to expose any explicit arguments.

Side effect, this should enable customization of colcon list for the rosdep collection step.

Related Issues

N/A

Completion Criteria

  • User can pass arbitrary extra arguments to colcon build (build step) and colcon list (in rosdep gathering step)

Implementation Notes / Suggestions

Suggest a defaults.yaml file at root of workspace, and build_workspace.sh sets the COLCON_DEFAULTS_FILE or COLCON_HOME environment variable appropriately. See https://colcon.readthedocs.io/en/released/user/configuration.html#defaults-yaml

Testing Notes / Suggestions

Create test workspace with 2 packages with different dependencies. Run rosdep collection script with defaults file that specifies --packages-select one_package. Check output script for its dependencies.

Continue above experiment into build phase and check that build directory only contains the one package

Remove all ROS-specific infrastructure

Description

Make this package a pure-python package.

After doing this, the package will no longer be testable via colcon. Since all tests were being invoked via colcon, successful completion of this story means introducing a new way to call tests. We should use Tox for this.

Related Issues

Part of Epic #102
Depends on #109

Completion Criteria

  • No ros2-specific infrastructure exists anymore
  • All existing tests can be run successfully via Tox for the python versions we claim to support

Things that will need to be removed or changed:

  • resource/
  • cross_compile.repos
  • requirements.txt
  • setup.py
  • setup.cfg
  • package.xml
  • README.md

Implementation Notes/Suggestions

Poco dependencies libz and libpcre not found

The packages depending on the Poco libraries fails if the pre-built binaries of Poco are used:
The PocoFoundationTargets.cmake file coming with the pre-built binaries have an hard-coded paths to /usr/lib/<arch>/libz.so and /usr/lib/<arch>/libpcre.so which makes the cross-compilation to fail.

The current workaround use symbolic links to the libz and libpcre libraries on /usr/lib/<arch>/ pointing to the actual libraries on the target filesystem.

A ongoing PR on the Poco project should fix this issue: pocoproject/poco#2599

Codecov CI action fails on PRs from forks

Description

When a Pull Request comes in from a fork, it can't access the secret codecov token, so the CI fails to upload codecov results and returns a failure. This was observed here: #131

Latest news is that there is a GitHub Actions API released today, and the codecov action is working to implement a solution - see codecov/codecov-action#29

For now, this issue can track that progress.

Expected Behavior

  • PRs from forks can upload codecov results

Actual Behavior

  • PRs from forks fail CI on the tasks that try to upload to codecov

To Reproduce

  • Open a PR from a fork of this repo

System (please complete the following information)

N/A

Additional context

Codecov is working on "Tokenless uploads" https://community.codecov.io/t/whitelist-github-action-servers-to-upload-without-a-token/491/15

Create a GH Action that runs cross-compile

Description

The cross-compile workflow can be simplified by having a GH Action run cross-compile and upload the workspace as an artifact.

The intended output of this issue is to release a GitHub Action to the marketplace that ROS workspace repositories can use to run this tool to cross-compile the workspace and upload the artifacts.

Related Issues

N/A

Completion Criteria

  • A ROS github repository can use a GitHub Action from the marketplace to cross-compile their package to any platform supported by this tool, and download the built artifact when it is done.

Implementation Notes / Suggestions

Not filled out

Testing Notes / Suggestions

  • Integration+Manual Testing:
    • Add cross-compile GH action to a simple ROS2 project repo on GitHub
    • Verify (manually) that the ws image is valid

Do not bust the Docker cache (via `rosdep install`) when only sources have changed

Description

When iterating on a workspace, any change that I make to the source (https://github.com/ros-tooling/cross_compile/blob/master/cross_compile/Dockerfile_ros#L100) busts the docker cache, and causes a full rosdep reinstall (https://github.com/ros-tooling/cross_compile/blob/master/cross_compile/Dockerfile_ros#L108) even if the needed dependencies haven't changed.

This rosdep install step can be one of the longest steps in the build process, especially for high level packages.

Completion Criteria

  • Changes to the workspace source that do not change the dependencies should not trigger a full rosdep reinstall. Ideally, only the build step should be run if possible. This will tighten the development iteration loop.

Implementation Notes

  • Potentially, can use a multi-stage Docker build
    • rosdep install --simulate outputs the installation commands that will be run, which can be dumped to a script
    • the sysroot creation step can run this script before taking the workspace sources - thus if a source change does not change the dependency list, the script will not change, and will not bust the cache

Testing Notes

  • Be aware that caching can break in subtle ways
  • Test pip-based rosdep dependencies
  • Test that changing a package.xml dependency busts the rosdep cache
  • The custom setup script / data directory can add rosdep rules, take this into account!
  • You could parse docker output for "used cache" to test whether this worked properly

Allow user to provide custom data directory to use in creating the sysroot

Target use case - a user wants to provide custom rosdep and pip rules from a local directory, in order to install nonstandard packages for their build.

To support this long term, let the user provide an arbitrary directory that their custom logic script can then use.

Requirements

  • add command line argument for the directory
  • copy directory to docker build context
  • copy directory into docker container at build time (before custom script execution)
  • add e2e test to make sure the data is available to custom script
  • make sure cache is not busted if contents of data dir don't change

`export_workspace_sysroot_image` takes too much time

For reference:

def export_workspace_sysroot_image(self) -> None:

Export takes much more time than build itself. On my PC build time of packages up to rcl takes about 15-20 mins and export took more than half-hour before I drop it - while docker cp directly from resulting image lasts for seconds.

As far as I can see, this is happening because export process itself is single-threaded, though I didn't noticed what actually takes so long.

Allow user to point this tool at their existing workspace, instead of requiring a specific directory structure

Description

Currently, there is a long section of the README describing how to properly set up your workspace. This requires manual user steps, which can be error prone and tedious. This tool should be able to handle any existing working colcon workspace, instead.

Related Issues

N/A

Completion Criteria

A user can run ros-cross-compile and have it build their existing workspace, instead of needing to structure sysroot/bin/ and sysroot/ros_ws/

Implementation Notes / Suggestions

The reason that it currently works the way it does is because we need the workspace in the Docker context, because building is part of the docker build step. Instead, if we refactor all actions that need the workspace to be part of a docker run, we won't need the Dockerfiles and the target workspace to ever be in the same directory structure.

We've already done this for the build, so really this just means making rosdep install a docker run step.

Testing Notes / Suggestions

The existing tests will need to be restructured, because they have a lot of logic around the particular directory structure that we dictate in the tool.

Question about the DDS implementation used in this project

Hi there,
It's exciting to see a whole new cross compile script. We are running into problem when doing cross compile in the old fashion with another DDS implementation(i.e., fastrtps is disabled).

I'm wondering when you test the cross compile script in this repository, are you using FastRTPS or RTI Connext Pro?

Thanks.

Release to PyPI

Description

Perform the first release of this package to PyPI so that it can be pip installed.

Related Issues

Part of Epic #102
Depends on #110
This is the final step for the Epic

Completion Criteria

  • The package has the name ros_cross_compile
  • I can pip3 install ros_cross_compile from production PyPI.
  • The package is not uploaded on every master push, only for explicit releases. For this ticket, this means a fully manual process is acceptable
  • Write a runbook to describe how to release the package
  • A nightly test installs cross_compile from PyPI and runs the e2e test (one each for test and production PyPI)

Implementation Notes/Suggestions

Allow for custom SKIP_ROSDEP_KEYS

Description

We have rosdep keys that cannot be resolved easily and are unimportant for the compilation of the package. They will be present on the target system

Related Issues

None

Completion Criteria

Optional skip-rosdep argument, or an environment variable that can be set in the custom-setup-script

Implementation Notes / Suggestions

Add a second --skip-keys argument to the rosdep install command with a user specified variable
or
Add to the SKIP_ROSDEP_KEYS environment variable that already exists

Testing Notes / Suggestions

Add a non-resolvable dependency to a test-package and ignore it (or not) with the new option.

Use local mixins in the build, not the remote master copy

EDIT: Narrowing this to one specific feature request:
The colcon mixins in this repository are not directly used, but instead are fetched from the master branch on GitHub. This can result in confusing situations:

  • Developers who change the mixins in their checkout will not see those changes be used in the build
  • Users who install cross_compile as a package may get a newer version of the mixins that could be potentially incompatible with the older version of the tool that they have installed

Instead we should copy the local mixins into the build container for use.

This should apply to both local developer checkouts and binary installations.


Original conversation for context below. Groomed this bug report as a feature request.

Request is to be able to specify a URI (file:// or http[s]://) for a colcon mixin repository, so that users can use their own custom remote or local mixins in place of the master branch mixins on this project.

Docker ADD can use a URI, so it should be fairly simple as a dockerfile argument https://docs.docker.com/engine/reference/builder/#add

Original Report

Initially reported in #35, but the PR did not address this problem itself.

The following line seems wrong to me:

RUN colcon mixin add cc_mixin \
    https://raw.githubusercontent.com/ros-tooling/cross_compile/master/mixins/index.yaml

Could we copy the mixin and use instead:

RUN colcon mixin add cc_mixin \
    file://.../mixins/index.yaml

The main issue with the current approach is that anyone developing on a feature branch will end up using the mixin from master. So it will be impossible to change the mixin locally w/o changing the Dockerfile.

Generally, it also open the door to other subtle issues where the script and the mixin aren't in sync because they pull from different locations.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.