ROS2 for Win32: rcl fails to compile: unresolved external symbol __InterlockedExchange64

asked 2019-06-03 11:24:20 -0600

marossa gravatar image

updated 2019-06-04 05:37:12 -0600

Hi,

I'm still trying to compile ROS2 for Windows x86. I changed colcon so it will call cmake for "Visual Studio 15 2017" without "Win64" (see: https://answers.ros.org/question/3242...)

I am using Windows 10 (tried 32bit and 64bit) and Visual Studio 2017 Community 15.0. I try to build using the "x86 Native Tools Command Prompt for VS 2017" (same error with x64). I get stuck while compiling rcl:

Error   LNK2019 unresolved external symbol __InterlockedExchangeAdd64 referenced in function _rcl_timer_init    rcl C:\dev\ros2\build\rcl\timer.obj 1   
Error   LNK2001 unresolved external symbol __InterlockedExchangeAdd64   rcl C:\dev\ros2\build\rcl\client.obj    1   
Error   LNK2001 unresolved external symbol __InterlockedExchangeAdd64   rcl C:\dev\ros2\build\rcl\context.obj   1   
Error   LNK2001 unresolved external symbol __InterlockedExchangeAdd64   rcl C:\dev\ros2\build\rcl\init.obj  1   
Error   LNK2001 unresolved external symbol __InterlockedExchangeAdd64   rcl C:\dev\ros2\build\rcl\time.obj  1   
Error   LNK2019 unresolved external symbol __InterlockedExchange64 referenced in function _rcl_send_request rcl C:\dev\ros2\build\rcl\client.obj    1   
Error   LNK2001 unresolved external symbol __InterlockedExchange64  rcl C:\dev\ros2\build\rcl\timer.obj 1

The linked libs are:

C:\dev\ros2\install\Lib\builtin_interfaces__rosidl_typesupport_c.lib
C:\dev\ros2\install\Lib\builtin_interfaces__rosidl_typesupport_cpp.lib
C:\dev\ros2\install\Lib\builtin_interfaces__rosidl_typesupport_fastrtps_c.lib
C:\dev\ros2\install\Lib\builtin_interfaces__rosidl_generator_c.lib
C:\dev\ros2\install\Lib\builtin_interfaces__rosidl_typesupport_fastrtps_cpp.lib
C:\dev\ros2\install\Lib\builtin_interfaces__rosidl_typesupport_introspection_c.lib
C:\dev\ros2\install\Lib\builtin_interfaces__rosidl_typesupport_introspection_cpp.lib
C:\dev\ros2\install\Lib\rosidl_typesupport_c.lib
C:\dev\ros2\install\Lib\rosidl_typesupport_cpp.lib
C:\dev\ros2\install\Lib\rosidl_typesupport_introspection_c.lib
C:\dev\ros2\install\Lib\rosidl_typesupport_introspection_cpp.lib
C:\dev\ros2\install\Lib\rcl_interfaces__rosidl_typesupport_c.lib
C:\dev\ros2\install\Lib\rcl_interfaces__rosidl_typesupport_cpp.lib
C:\dev\ros2\install\Lib\rcl_interfaces__rosidl_typesupport_fastrtps_c.lib
C:\dev\ros2\install\Lib\rcl_interfaces__rosidl_generator_c.lib
C:\dev\ros2\install\Lib\rcl_interfaces__rosidl_typesupport_fastrtps_cpp.lib
C:\dev\ros2\install\Lib\rcl_interfaces__rosidl_typesupport_introspection_c.lib
C:\dev\ros2\install\Lib\rcl_interfaces__rosidl_typesupport_introspection_cpp.lib
C:\dev\ros2\install\Lib\rmw_implementation.lib
C:\dev\ros2\install\Lib\rmw.lib
C:\dev\ros2\install\Lib\rcutils.lib
C:\dev\ros2\install\Lib\rosidl_generator_c.lib
C:\dev\ros2\install\Lib\rcl_logging_noop.lib
kernel32.lib
user32.lib
gdi32.lib
winspool.lib
shell32.lib
ole32.lib
oleaut32.lib
uuid.lib
comdlg32.lib
advapi32.lib

Any ideas how to fix this?

Thank you in advance marossa


Edit:

Other things, that are different to the "normal" 64bit build: OpenSSL 32bit (1.0.2s), Python 3.7 32bit, self compiled for x86: tinyxml2, tinyxml (built with /MD instead of /MT).

I updated my source files (they were about a week old) and as @sloretz pointed out, there is a test_atomics file in in rcutils now. As expected, it fails with the same error. I will append the full stdout_stderr.log to give you the maximum information possible:

-- The C compiler identification is MSVC 19.10.25027.0
-- The CXX compiler identification is MSVC 19.10.25027.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10 ...
(more)
edit retag flag offensive close merge delete

Comments

I'm not certain, but it could be that __InterlockedExchangeAdd64 is unsupported on x86 platforms.

gvdhoorn gravatar image gvdhoorn  ( 2019-06-03 11:45:01 -0600 )edit

Single underscore _InterlockedExchangeAdd64 is listed with arch 'x86, ARM, x64` in the documentation for VS 2017 and 2019, and is listed in intrinsics available on all architectures. Here's where it's used in rcutils

sloretz gravatar image sloretz  ( 2019-06-03 12:00:41 -0600 )edit

The function does not seem to be used directly by rcl_timer_init, or anything in ros2/rcl. Could it be that InterlockedExchange64 is being used on Windows to implement one of the C runtime functions?


Edit: used here (among other places) and InterlockedExchange64 comes in via this.

gvdhoorn gravatar image gvdhoorn  ( 2019-06-03 12:05:17 -0600 )edit

I'd guess double underscore version is an implementation of the single underscore version which the rcl timer uses via rcutils_atomic_load_int64_t. @marossa, do the tests for rcutils pass? There is a test that checks atomics. If that works but rcl doesn't build, maybe there's some windows dependency not being properly exported?

sloretz gravatar image sloretz  ( 2019-06-03 12:17:08 -0600 )edit

@sloretz, my ros2.sources was from May 27th with rcutils in ver. 0.6.2 (without the test_atomics). I updated my sources and now it fails, as you expected, in rcutils with the same error. Should I post the full stdout_stderr.log as an answer? It's too long for the comment. Edit: I guess it can't hurt: https://pastebin.com/CbEWncng

marossa gravatar image marossa  ( 2019-06-04 03:53:05 -0600 )edit

@marossa: just edit your original question text with long updates. I've done that for you, but you may want to add some context.

gvdhoorn gravatar image gvdhoorn  ( 2019-06-04 03:57:06 -0600 )edit

I'm still looking for a solution to the issue. I'm afraid I'm not deep enough into C++ to fix this myself. Any directions you could hint me? Why is VS looking for the double underscore instead of the single underscore?

marossa gravatar image marossa  ( 2019-06-07 08:25:46 -0600 )edit

I'm not speaking for @sloretz, but personally, this sounds more like a Windows specific linking problem than a ROS problem. You're trying to solve a linking problem while building ROS 2, true of course, but it might be beneficial to you to widen where you look for support.

gvdhoorn gravatar image gvdhoorn  ( 2019-06-07 09:16:27 -0600 )edit