Ros2 fails to build osrf_testing_tools_cpp with Visual Studio 15.8
Hi,
Is it correct that ROS2 on windows fails to build many of its default packages?
I precisely followed these steps to set up my environment for ROS2 bouncy and everything went fine. I installed opensplice, but had the same issues when trying to compile before I installed it. I checked my PATH
as well.
When I run
colcon build --merge-install
every now and then, it fails to compile a package, which "exited with code 1". I then put an AMENT_IGNORE
in the respecting folder and try again, just to see if it somehow can compile. But shouldn't these packages compile without failure?
To be precise, these packages fail to build: pluginlib, rviz, osrf, rcutils, demos, rmw, rcl_interfaces, std_srvs, std_msgs. I also ignored the following: examples, examples_interfaces, rmw_connext, rmw_typesupport_connext.
Also, when I
cd \dev\ros2
call C:\opensplice67\HDE\x86_64.win64\release.bat
call install\local_setup.bat
ros2
the setup runs fine with no output, but I get "command not found" on ros2. Just as in this question.
Can anyone give me at least a hint? I would really appreciate it. Thank you in advance!
EDIT:
Program versions I use:
- Visual Studio: Community 2017 (15.8.1)
- OpenSplice: 6.7
- colcon: latest version as of now (I don't know how to find the version number)
- Python: 3.7
- Qt5: 5.10.0 (but I have also installed: 5.10.1, 5.11.0, 5.11.1)
It seems that when building packages fail to compile because they depend on each other but prevent their dependencies from being built while failing themselves. So when compiling step-by-step while adding one package each step (and unfortunately in the right but unknown order), as of now, at least some of the packages listed above compile.
While other packages compile because they only had missing dependencies, osrf_testing_tools_cpp
gives me:
C:\dev\ros2>colcon build --packages-select osrf_testing_tools_cpp --merge-install --event-handler console_cohesion+
Starting >>> osrf_testing_tools_cpp
[4.039s] colcon.colcon_core.event_reactor ERROR Exception in event handler extension 'console_cohesion': 'charmap' codec can't decode byte 0x81 in position 2981: character maps to <undefined>
Traceback (most recent call last):
File "c:\python37\lib\site-packages\colcon_core\event_reactor.py", line 78, in _notify_observers
retval = observer(event)
File "c:\python37\lib\site-packages\colcon_output\event_handler\console_cohesion.py", line 49, in __call__
content = h.read()
File "c:\python37\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 2981: character maps to <undefined>
Failed <<< osrf_testing_tools_cpp [ Exited with code 1 ]
Summary: 0 packages finished [3.67s]
1 package failed: osrf_testing_tools_cpp
After downgrading to Visual Studio Community 2017 (15.7.6), not only osrf_testing_tools_cpp, but all packages not directly related to connext compile fine. Also, the build finishes and is not aborted (as was before). (See accepted answer)
Bouncy is supposed to compile 'cleanly' on Win10, but things can of course change. Windows 10 is a bit of a 'moving target', so if any of the dependencies change versions then some things could break.
It might help if you could list the versions of some important components: VS, OpenSplice, ..
..,
colcon
, Python and Qt5.But above all:
this is too vague. Without actual error messages (copy-pasted) we will only ever be able to guess at what might be wrong.
Please add more information to your question.
colcon does not give me error messages! I am currently working my way through this. As of now, osrf_testing_tools_cpp fails to build with colcon but shows no reason. I will add my version numbers but they are exactly as in the tutorial...
can you try building one of the failing packages with the following option added to the command line:
That should provide you with a bit more information.
That is why I asked the OP to report exact versions. Visual Studio is one such moving target I referred to earlier. It almost makes you wonder whether they don't have enough test coverage at MS when checking their VS releases.
re: your latest edit: this could have nothing to do with it, but are you running a Windows 10 with a German locale configured?
@gvdhoorn: yes
If downgrading VS doesn't work (and I have a bit of a feeling it won't, but let's see), could you add a English (US) locale and switch to that. Then see if something changes? Be sure to (at least) log-out and then back in.
You should be able to revert back to German without issue afterwards.