0

I have cross compiled a software for an HummingBoard-Pro (arm processor).

The software just receives some data using the lcm protocol. If I use the cross compiled software, the data received by the application are invalid, while if I use on-board compiled software everything works fine.

-The software is exactly the same! -I cross compiled using cmake and a specific arm toolchain.

Output example of cross compiled sw:

first value     5.73599e+107
second value    5.73599e+107
third value     5.73599e+107

Output example of on board compiled sw:

first value     1
second value    2
third value     3

Note: It's my first cross compilation attempt so probably something goes wrong but I haven't really idea about what.

CMakelists file

cmake_minimum_required(VERSION 3.1)

set(main_project_dir     ${CMAKE_CURRENT_SOURCE_DIR}) 

set(external_dir         ${main_project_dir}/external) 
set(external_lcm_dir     ${external_dir}/lcm_dir) 
set(external_lcm         ${external_lcm_dir}/lcm) 
set(external_lcm_build   ${external_lcm}/build) 
set(external_lcm_gen_exe  /usr/local/bin/lcm-gen)


set(lcm_input_file            ${main_project_dir}/lcm_format_files/lcm_input_files/indrive.sensors.vanet.lcm)
set(lcm_libraries             ${main_project_dir}/external/lcm_dir/lcm/build/lcm)
set(lmc_libraries_header      ${main_project_dir}/external/lcm_dir/lcm/)
set(lcm_autogenerated_dir     ${main_project_dir}/build/lcm_autogenerated_classes)


add_custom_target(
  generate-lcm
  COMMAND ${external_lcm_gen_exe}  -x ${lcm_input_file} --cpp-hpath ${lcm_autogenerated_dir}
  COMMENT "=================== Generating lcm files..."
)

add_subdirectory(testSender)
add_subdirectory(testReceiver)

TOOLCHAIN FILE

SET (CMAKE_SYSTEM_NAME Linux)
SET (CMAKE_SYSTEM_VERSION 1)
SET (CMAKE_SYSTEM_PROCESSOR arm)

INCLUDE_DIRECTORIES(/usr/hummingboard/usr/include /usr/hummingboard/include /usr/hummingboard/usr/include/arm-linux-gnueabihf/)
LINK_DIRECTORIES(/usr/hummingboard/usr/lib  /usr/hummingboard/lib  /usr/hummingboard/lib/arm-linux-gnueabihf )


SET(CMAKE_PREFIX_PATH /usr/arm-linux-gnueabihf/lib/
                      /usr/hummingboard/
                      /usr/hummingboard/lib/arm-linux-gnueabihf/
                      /usr/hummingboard/usr
                      /usr/hummingboard/usr/lib/arm-linux-gnueabihf/
                      )


SET (CMAKE_C_COMPILER  /usr/bin/arm-linux-gnueabi-gcc)
SET (CMAKE_CXX_COMPILER /usr/bin/arm-linux-gnueabi-g++)



SET (CMAKE_FIND_ROOT_PATH /usr/hummingboard/ /usr/hummingboard/usr)

SET (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

SET (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
SET (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Franconet
  • 41
  • 1
  • 10
  • Without viewing `CMakeLists.txt` (in form of [mcve]) we can only guess. Probably, this script takes some *host* parameters instead of *target* ones. – Tsyvarev Jun 19 '17 at 17:24
  • The value `5.73599e+107` is `0x7f800000` which means [infinite](https://stackoverflow.com/questions/35022082/assign-infinity-to-float). So a wild guess is that your floating point settings are wrong. Please compare the compiler command lines between both builds (working vs. non-working) using [verbose makefiles](https://stackoverflow.com/questions/2670121/using-cmake-with-gnu-make-how-can-i-see-the-exact-commands). – Florian Jun 19 '17 at 18:34
  • I added the requested files – Franconet Jun 20 '17 at 08:26
  • Your toolchain file looks like a strange mixture of two toolchains. I would e.g. expect there to be a `/usr/hummingboard/bin` directory. Or shouldn't there be a `arm-linux-gnueabihf-gcc`? – Florian Jun 20 '17 at 19:58

1 Answers1

0

Turning my comments into an answer

Your toolchain file looks like a mixture of two GNU toolchains, which is not allowed and could explain strange behavior of your software.

I would e.g. expect there to be a /usr/hummingboard/bin directory. And shouldn't there be a arm-linux-gnueabihf-gcc to match with /usr/arm-linux-gnueabihf/lib/.

My guess would be that you are mixing hard-float (hf) with soft-float libraries and native- with cross-compilers.

It gets visible with the value 5.73599e+107 = 0x7f800000 which means infinite.

To find the root-cause I would recommend to check your floating point settings. Please compare the compiler command lines between both builds (working vs. non-working) using verbose makefiles.

References

Florian
  • 39,996
  • 9
  • 133
  • 149