Open dyumanaditya opened 3 years ago
I'm not a windows user myself, but I know that @jontje uses the driver on Windows.
From the logs you show it appears abb_rapid_msgs
is failing to configure for some reason.
Could you add a little more detail as to what your workflow is exactly?
How did you install ROS? How did you create your workspace? How do you invoke catkin_make_isolated
exactly?
Please be specific, don't assume we know anything and try to refrain from describing commands you run, instead copy-paste them verbatim into your comment.
Finally: does catkin_make
instead of catkin_make_isolated
work?
Be sure to delete the build
, devel
and/or build_isolated
and devel_isolated
between attempts.
Thanks for the quick reply, I installed ROS Noetic on my Windows 10 system by following the instructions on the ROS page.
As advised on the installation website, I'm using the x64 Native Tools Command Prompt for VS 2019 terminal running as admin and sourced to the correct setup file in the ROS package.
I created a catkin_ws
folder in my C drive under Users/(my name)
, and initialized the catkin_ws
with catkin_init_workspace
. I then followed the build instructions from this repository. I modified "melodic" to "noetic" in the 5th line, and ran catkin_make_isolated
instead of catkin build
(which apparently doesn't work on Windows). I tried building the package using catkin_make
which failed as well.
There is nothing else inside my catkin_ws/src
folder except for this package.
Please let me know if you need more information about anything.
Could you please remove everything from the src
space of your workspace, git clone
the ros-industrial/abb_robot_driver_interfaces
repository into it and then move the abb_egm_msgs package to the root of the src
space. Remove the abb_robot_driver_interfaces
directory from src
after that.
Also remove any build
, devel
and/or build_isolated
and devel_isolated
folders which may be present in catkin_ws
.
You should have only this:
catkin_ws/
src/
abb_egm_msgs
then try to build that (after having sourced things, in the correct terminal, etc).
If that fails as well, this starts to look like a more general problem with your ROSonWindows configuration, and no longer something specific to the driver here (or related packages).
I followed your instructions and was able to build abb_egm_msgs
without a problem using catkin_make_isolated
.
What could be going wrong with the building of the abb_robot_driver
package?
What could be going wrong with the building of the
abb_robot_driver
package?
a step-by-step approach would likely be the easiest way to diagnose this.
Use the same procedure as in https://github.com/ros-industrial/abb_robot_driver/issues/17#issuecomment-790553337, but progressively add more packages.
At some point the build will fail again.
Then we can start to try and understand why that's happening.
And as I wrote earlier: always remove any build
, devel
and/or build_isolated
and devel_isolated
folders which may be present in catkin_ws
before running another iteration.
I've narrowed down the problem to the abb_robot_driver_interfaces/abb_rapid_msgs
package by iteratively adding more packages.
Here is the error from the terminal after I ran catkin_make_isolated
:
The content of CMakeOutput.log
and CMakeError.log
is the same as what was posted in the first post.
Determining if the include file pthread.h exists failed with the following output:
This is the first line of the CMakeError.log
, which for some reason was not copied correctly in the first post until now (edited).
Ok.
So first: I don't think what you find in CMakeError.log
is related.
I believe there is a problem with some of the characters in some of the .msg
files in abb_rapid_msgs
. Linux and OSX are fine with this, but Windows is a bit stricter with the codepages and can't decode the bytes to proper characters.
These two .msg
s are suspicious:
the links point to the specific lines which I believe contain the potentially "offending" characters.
Could you try to remove the °
from RobTarget.msg
first and see whether things build then.
If they don't, remove the “
from ExtJoint.msg
and try again.
@DyumanAditya: could you check whether https://github.com/ros-industrial/abb_robot_driver_interfaces/pull/9 solves your build issues?
Or at least this build issue?
Both changes were necessary for the abb_robot_driver_interfaces/abb_rapid_msgs
package to build successfully.
After fixing this, the build failed further down the line: in the abb_robot_driver/abb_egm_hardware_interface
package.
This is the error in the terminal after running catkin_make_isolated
:
After running cd C:\Users\Dyuman\catkin_ws\build_isolated\abb_egm_hardware_interface
and then C:\Users\Dyuman\catkin_ws\devel_isolated\abb_robot_cpp_utilities\env.bat ninja -j8 -l8
to reproduce this error, this is the output message in the terminal:
Is this some sort of syntax error in one of the files?
Is this some sort of syntax error in one of the files?
No, not really.
This is a problem with ros_control
, or more specifically, the hardware_interface
package of ros_control
. Your problem is similar/identical to Build kuka_experimental package on Windows 10 ROS1 noetic on ROS Answers (it's about kuka_experimental
, but that also uses ros_control
).
The error is this (from here):
enum class SwitchState
{
DONE,
ONGOING,
ERROR
};
ERROR
is #define
d in some Windows header, which causes a problem here in this enum
.
(Edit: or at least: this is my understanding, perhaps @ooeygui will correct me)
I'm not really sure why @jontje hasn't run into this, but perhaps @ooeygui can help us come up with a work-around.
He's worked on the kuka_experimental
issue https://github.com/ms-iot/ROSOnWindows/issues/294 (in https://github.com/ms-iot/kuka_experimental/pull/2).
@traversaro would perhaps have run into this problem with hardware_interface
on Windows?
I'm not a windows user myself, but I know that @jontje uses the driver on Windows.
Yes, I am using the driver on Windows, though I have only used it with ROS Melodic, and if I remember correctly, then I just followed the Melodic installation instructions found here.
I'm not really sure why @jontje hasn't run into this
Regarding compiling the driver, then I just downloaded the driver packages and build them with catkin_make_isolated
. I haven't needed to make any local changes, not even related to the non-ASCII characters in the abb_rapid_msg
package.
@traversaro would perhaps have run into this problem with
hardware_interface
on Windows?
I never used ros_control
on Windows. However, the ERROR
macro collision with the macros defined in Windows.h is unfortunately quite common. The most common workaround is to avoid as much as possible to include Windows.h
in header files, and only include it in the compilation unit that they use it, and even try to include it as last header. A more complicate workaround is to have something to explicitly define and undefine the offending macros, as done in protobuf with the port_def.inc
and port_undef.inc
:
@traversaro wrote:
I never used
ros_control
on Windows.
https://github.com/ms-iot/ROSOnWindows/issues/294#issuecomment-711885007, hmm? :)
A more complicate workaround is to have something to explicitly define and undefine the offending macros, as done in protobuf with the
port_def.inc
andport_undef.inc
hm, annoying.
And it's also not here, but in ros_control
. @bmagyar has anyone complained about this (ie: ros_control
on Windows) before to your knowledge? Would patches to fix this be merged quickly?
Note: this is not ros2_control
, but plain ros_control
.
@traversaro wrote:
I never used
ros_control
on Windows.ms-iot/ROSOnWindows#294 (comment), hmm? :)
Quoting for the issue:
because we needed a non-ROS package to consume it as a dependency, so even if the fix was upstreamed we could not use it.
Our local modification transformed the RSI driver in a standalone library and switched to use cartesian interface instead of the joint one, so the first thing done was to remove any ros_control dependency.
Our local modification transformed the RSI driver in a standalone library and switched to use cartesian interface instead of the joint one, so the first thing done was to remove any ros_control dependency.
I would've used a different RSI implementation in that case, but ok, clear.
And it's also not here, but in ros_control. @bmagyar has anyone complained about this (ie: ros_control on Windows) before to your knowledge? Would patches to fix this be merged quickly?
To clarify, the offending include is in ros_control, but the problem only appears if someone is including windows.h, did you tracked who is including windows.h ?
No. I don't have a Windows build environment setup.
Compiler output is in https://github.com/ros-industrial/abb_robot_driver/issues/17#issuecomment-791134213 :(
Edit: and confusingly @jontje doesn't run into the problem: https://github.com/ros-industrial/abb_robot_driver/issues/17#issuecomment-791311493.
Our local modification transformed the RSI driver in a standalone library and switched to use cartesian interface instead of the joint one, so the first thing done was to remove any ros_control dependency.
I would've used a different RSI implementation in that case, but ok, clear.
Yes, effectively over time our became a completely separate RSI implementation (also class names and everything else is different, and all the XML message changed).
off-topic, but:
effectively over time our became a completely separate RSI implementation (also class names and everything else is different, and all the XML message changed).
would be interesting to take a look. There isn't that much public code dealing with RSI.
It would be really nice if KUKA could provide a reference implementation of a properly written RSI server. That would significantly reduce the maintenance of all these RSI interfaces.
Hi, Thanks for the answers.
This is a problem with
ros_control
, or more specifically, thehardware_interface
package ofros_control
.
None of the installed packages (as listed here) in my catkin_ws
show any sign of a ros_control
package, or am I missing something? Or is ros_control
installed by default with ROS ?
The next step as I understand will be to search for a file that has #include Windows.h
, and try the workaround that @traversaro mentioned. And this file is located somewhere in ros_control
.Is that corrrect?
@DyumanAditya wrote:
None of the installed packages (as listed here) in my
catkin_ws
show any sign of aros_control
package, or am I missing something?
perhaps the fact that abb_robot_driver
is a ros_control
-based implementation of a hardware_interface
? :)
Or is
ros_control
installed by default with ROS ?
Not "with ROS". Perhaps with "ROS Noetic as ported and distributed by MS".
The next step as I understand will be to search for a file that has
#include Windows.h
, and try the workaround that @traversaro mentioned. And this file is located somewhere inros_control
.Is that corrrect?
Well, sort-of.
It's not entirely certain there is anything including that header directly.
That's why I asked @ooeygui whether he's aware of any existing issues with the hardware_interface
package. If they'd already fixed or worked around it, it would save us some effort.
Update: I installed ROS Melodic, and tried building the package. I didn't have the problem relating to the non-ASCII characters but ended up with the same final error as with Noetic. Don't know how much this helps, but thought I'd put it up.
No. I don't have a Windows build environment setup.
Compiler output is in #17 (comment) :(
Ah, I see thanks. The affected compilation unit seems https://github.com/ros-industrial/abb_robot_driver/blob/master/abb_egm_hardware_interface/src/egm_hardware_interface.cpp .
In my experience Protobuf headers may include Windows.h
, so a first test that it may be worth is to do is move the #include <google/protobuf/text_format.h>
from https://github.com/ros-industrial/abb_robot_driver/blob/master/abb_egm_hardware_interface/src/egm_hardware_interface.cpp#L40 to be included after #include "abb_egm_hardware_interface/egm_hardware_interface.h"
.
@DyumanAditya wrote:
Update: I installed ROS Melodic, and tried building the package. I didn't have the problem relating to the non-ASCII characters but ended up with the same final error as with Noetic. Don't know how much this helps, but thought I'd put it up.
that's indeed useful. And a bit confusing, as that's essentially @jontje's setup. Unless of course you have a more recent install of some package.
@traversaro wrote:
In my experience Protobuf headers may include
Windows.h
, so a first test that it may be worth is to do is move the#include <google/protobuf/text_format.h>
from https://github.com/ros-industrial/abb_robot_driver/blob/master/abb_egm_hardware_interface/src/egm_hardware_interface.cpp#L40 to be included after#include "abb_egm_hardware_interface/egm_hardware_interface.h"
.
@DyumanAditya: could you try this?
@traversaro wrote:
In my experience Protobuf headers may include Windows.h, so a first test that it may be worth is to do is move the #include <google/protobuf/text_format.h> from https://github.com/ros-industrial/abb_robot_driver/blob/master/abb_egm_hardware_interface/src/egm_hardware_interface.cpp#L40 to be included after #include "abb_egm_hardware_interface/egm_hardware_interface.h" .
I tried this, and get essentially the same errors, although it looks slightly different towards the end:
Really OT, but on the other hand I tried to provided a hopefully useful hint in the previous comment.
off-topic, but:
effectively over time our became a completely separate RSI implementation (also class names and everything else is different, and all the XML message changed).
would be interesting to take a look. There isn't that much public code dealing with RSI.
Yes, I will be happy to share it. Especially the semantics of the cartesian orientation correction is quite a mistery, we got it work from trial and error (see https://github.com/cjlh/kuka-rsi-ros-interface/issues/1 for a related discussion).
It would be really nice if KUKA could provide a reference implementation of a properly written RSI server. That would significantly reduce the maintenance of all these RSI interfaces.
Yes, kuka_librsi
would be great. In particular, most of the RSI implementations I found kind of hardcode in C++ code the specific structure of the message that is specified in the RSI .xml
file (for example https://github.com/ros-industrial/kuka_experimental/blob/indigo-devel/kuka_rsi_hw_interface/krl/KR_C4/ros_rsi_ethernet.xml), so anytime the user modify the .xml needs also to modify the C++ parser code. A RSI parser that loads the expected structure of the RSI message from .xml files would be extremely handy. fyi @ahoarau .
@traversaro wrote:
In my experience Protobuf headers may include Windows.h, so a first test that it may be worth is to do is move the #include <google/protobuf/text_format.h> from https://github.com/ros-industrial/abb_robot_driver/blob/master/abb_egm_hardware_interface/src/egm_hardware_interface.cpp#L40 to be included after #include "abb_egm_hardware_interface/egm_hardware_interface.h" .
I tried this, and get essentially the same errors, although it looks slightly different towards the end:
Apparently something else brings in protobuf headers. Then the only alternative is to either generate the full header include tree to understand who is including it (by adding /showIncludes
to CMAKE_CXX_FLAGS
, not sure how you do that via catkin), or just add a:
#pragma push_macro("ERROR")
#undef ERROR
before the problematic ros_control include, and:
#pragma pop_macro("ERROR")
after. However, this is not a great solution if some other part of the code use the ERROR
as defined by ros_control
.
or just add a:
#pragma push_macro("ERROR") #undef ERROR
before the problematic ros_control include, and:
#pragma pop_macro("ERROR")
after. However, this is not a great solution if some other part of the code use the
ERROR
as defined byros_control
.
Do you have any suggestions as to where I can look for the problematic ros_control include?
@traversaro, this is what I did:
in abb_robot_driver/abb_egm_hardware_interface/src/egm_hardware_interface.cpp
I modified the line #include "abb_egm_hardware_interface/egm_hardware_interface.h"
to:
#pragma push_macro("ERROR")
#undef ERROR
#include "abb_egm_hardware_interface/egm_hardware_interface.h"
#pragma pop_macro("ERROR")
And in abb_robot_driver/abb_egm_state_controller/src/egm_state_controller.cpp
, I modified the line #include "abb_egm_state_controller/egm_state_controller.h"
to :
#pragma push_macro("ERROR")
#undef ERROR
#include "abb_egm_state_controller/egm_state_controller.h"
#pragma pop_macro("ERROR")
I was able to build the package successfully! What are the possible repercussions that might arise from this modification though?
And it's also not here, but in ros_control. @bmagyar has anyone complained about this (ie: ros_control on Windows) before to your knowledge?
We received a couple of PRs from the "ROS guys" at Microsoft, mostly in 2019. Nothing major, mostly tweaks to how certain things were expressed in the code to make it compile on Windows.
Would patches to fix this be merged quickly?
Of course. Provided that they are not breaking and have some testing (if not covered already by existing tests).
I just realized that at RoboStack we are building ros-control packages for Windows, and there are no Windows-specific patches for ros_control, see https://github.com/RoboStack/ros-noetic/tree/master/patch (unless I am wrong, @Tobias-Fischer feel free to correct me). Then probably the problem does not arise when building ros_control on its own as no one in its compilation units is including Windows.h .
@traversaro @bmagyar: I'm not sure, but there seem to be some ERROR
and OK
related changed in https://github.com/ms-iot/kuka_experimental/pull/2.
A hold over from early DOS, ERROR, OK and several other common words were #defined. For source compatibility, these were brought into headers brought into windows.h. #define is not namespaced, so any user downstream will have these overwritten - and ultimately have a duplicate define or build break.
For most of ROS, we were able to resolve this, as ROS headers do include windows,h, but have an #undef ERROR
to work around the ROS versions of ERROR, including those in msg files.
Internally to boost, the headers will include windows,h, which will redefine ERROR. In order to not pollute the code with Windows specific things, we typically reorder headers if that resolves the build break, otherwise add an additional #undef ERROR after boost headers.
I hope that helps explaining the root cause.
Thanks @ooeygui, this seems to confirm what @traversaro also described.
Would it make sense to put the work-arounds from https://github.com/ros-industrial/abb_robot_driver/issues/17#issuecomment-791497279 somewhere in ros_control
(wrapped in suitable #ifdef
s), or would it be more prudent to do this on a case-by-case basis?
I believe @lilustga commented here but then removed it.
@lilustga: I believe what you suggested was already tried by @DyumanAditya, could you confirm?
@gavanderhoorn, Saw Lou's prior comment and realized it was redundant so removed it.
Would it make sense to put the work-arounds from https://github.com/ros-industrial/abb_robot_driver/issues/17#issuecomment-791497279 somewhere in
ros_control
(wrapped in suitable#ifdef
s), or would it be more prudent to do this on a case-by-case basis?
@ooeygui @lilustga, what's your opinion?
It looks like ERROR is used both in the SwitchState
enum where this conflict occurred as well as the JointCommandModes
enum in joint_mod_interface.h. ERROR is not pound defined in ros_control
and I don't believe the enums will be affected by the pop_macro. Given this, it would be safe to use this workaround within ros_control
.
@ooeygui, thoughts?
@gavanderhoorn We have put in #undef error
in some header files attempting to work around this problem. Windows.h can leak in various places after the workarounds are in place, which triggers this bug downstream. We have tried disabling the Windows include causing this problem (wingdi.h), but that negatively impacts other places. Unfortunately, we're at a point that this needs to be worked around on a case by case basis.
My 2cents: wouldn't it be easier to bind the abb driver binaries somehow in a Unix environment so you don't need to go through this Herculean (or perhaps Don Quixoten?) effort? It will be quite hard to ensure everything keep working over time...
Could you clarify what you mean by that @bmagyar ?
Are you saying we should prevent people from trying to build this on Windows?
@bmagyar Keeping it building is quite easy - github actions can be added to build on Linux and Windows during CI. Check out https://aka.ms/ros for the docs.
Sorry for the previous post, for a moment I misunderstood and thought it is to build some windows stuff for the driver to work on Linux
I'd still throw in the idea of trying to avoid the offending header completely.
On Thu, 11 Mar 2021, 20:47 G.A. vd. Hoorn, @.***> wrote:
Could you clarify what you mean by that @bmagyar https://github.com/bmagyar ?
Are you saying we should prevent people from trying to build this on Windows?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ros-industrial/abb_robot_driver/issues/17#issuecomment-797038435, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA24PYMYIG2G7F7DEOW7PXTTDET75ANCNFSM4YS7D4WA .
@bmagyar wrote:
I'd still throw in the idea of trying to avoid the offending header completely.
depending on your perspective, the offending header would be one of the core Windows headers, or the one in ros_control
which defines the ERROR
members in those enum
s ;)
I'm not sure which of the two would be easier to get rid of, so it seems we're stuck with adding some work-arounds.
Thanks to https://github.com/ros-controls/ros_control/pull/492 I found https://github.com/ros-controls/ros_control/pull/397, that seems to be related to this discussion.
Thanks for that. The fix in https://github.com/ros-simulation/gazebo_ros_pkgs/pull/1023 seems like something which we could use here.
It isn't a hack, clearly visible in the build script and there's precedence for it in a package which sees a lot of usage.
I'm very much in support of the -DNOGDI
approach!
May I ask if is there any official fix to solve the compile error? Because I'm getting the same problem compiling abb_robot_driver on Windows with ROS Noetic as @DyumanAditya.
Hi @enricovillagrossi !
Based on the latest messages from @bmagyar and @gavanderhoorn you probably can try to add:
## Restrict Windows header namespace usage
if(WIN32)
add_definitions(-DNOGDI)
endif()
in https://github.com/ros-industrial/abb_robot_driver/blob/master/abb_egm_hardware_interface/CMakeLists.txt#L105 (or anyhow somewhere before the add_library
).
Hi, When I try to build the package on Windows using catkin_make_isolated (because catkin build isn't supported on Windows) this is my CMakeError log:
Click to expand
``` Determining if the include file pthread.h exists failed with the following output: Change Dir: C:/Users/Dyuman/catkin_ws/build_isolated/abb_rapid_msgs/CMakeFiles/CMakeTmp Run Build Command(s):C:/PROGRA~2/MICROS~2/2019/COMMUN~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe cmTC_d3d33 && [1/2] Building C object CMakeFiles\cmTC_d3d33.dir\CheckIncludeFile.c.obj FAILED: CMakeFiles/cmTC_d3d33.dir/CheckIncludeFile.c.obj C:\PROGRA~2\MICROS~2\2019\COMMUN~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /FoCMakeFiles\cmTC_d3d33.dir\CheckIncludeFile.c.obj /FdCMakeFiles\cmTC_d3d33.dir\ /FS -c CheckIncludeFile.c CheckIncludeFile.c(1): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory ninja: build stopped: subcommand failed. ```And this is my CMakeOutput log:
Click to expand
``` The system is: Windows - 10.0.19042 - AMD64 Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded. Compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29333/bin/Hostx64/x64/cl.exe Build flags: Id flags: The output was: 0 Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29337 for x64 Copyright (C) Microsoft Corporation. All rights reserved. CMakeCCompilerId.c Microsoft (R) Incremental Linker Version 14.28.29337.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:CMakeCCompilerId.exe CMakeCCompilerId.obj Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.exe" Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.obj" The C compiler identification is MSVC, found in "C:/Users/Dyuman/catkin_ws/build_isolated/abb_rapid_msgs/CMakeFiles/3.18.2/CompilerIdC/CMakeCCompilerId.exe" Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded. Compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29333/bin/Hostx64/x64/cl.exe Build flags: Id flags: The output was: 0 Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29337 for x64 Copyright (C) Microsoft Corporation. All rights reserved. CMakeCXXCompilerId.cpp Microsoft (R) Incremental Linker Version 14.28.29337.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:CMakeCXXCompilerId.exe CMakeCXXCompilerId.obj Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.exe" Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.obj" The CXX compiler identification is MSVC, found in "C:/Users/Dyuman/catkin_ws/build_isolated/abb_rapid_msgs/CMakeFiles/3.18.2/CompilerIdCXX/CMakeCXXCompilerId.exe" Detecting C compiler ABI info compiled with the following output: Change Dir: C:/Users/Dyuman/catkin_ws/build_isolated/abb_rapid_msgs/CMakeFiles/CMakeTmp Run Build Command(s):C:/PROGRA~2/MICROS~2/2019/COMMUN~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe cmTC_c4114 && [1/2] Building C object CMakeFiles\cmTC_c4114.dir\CMakeCCompilerABI.c.obj [2/2] Linking C executable cmTC_c4114.exe Detecting CXX compiler ABI info compiled with the following output: Change Dir: C:/Users/Dyuman/catkin_ws/build_isolated/abb_rapid_msgs/CMakeFiles/CMakeTmp Run Build Command(s):C:/PROGRA~2/MICROS~2/2019/COMMUN~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe cmTC_92086 && [1/2] Building CXX object CMakeFiles\cmTC_92086.dir\CMakeCXXCompilerABI.cpp.obj [2/2] Linking CXX executable cmTC_92086.exe ```Can this package be build on Windows? If not, what is the best way to use this package on Ubuntu and run RobotStudio on Windows?