Windows build failing #17
Comments
|
I'm not a windows user myself, but I know that @jontje uses the driver on Windows. From the logs you show it appears 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 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 Be sure to delete the |
|
Thanks for the quick reply, 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 There is nothing else inside my |
|
Could you please remove everything from the Also remove any You should have only this: 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 What could be going wrong with the building of the |
a step-by-step approach would likely be the easiest way to diagnose this. Use the same procedure as in #17 (comment), 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 |
|
I've narrowed down the problem to the Here is the error from the terminal after I ran Click to expandThe content of This is the first line of the |
|
Ok. So first: I don't think what you find in I believe there is a problem with some of the characters in some of the These two the links point to the specific lines which I believe contain the potentially "offending" characters. Could you try to remove the If they don't, remove the |
|
@dyumanaditya: could you check whether ros-industrial/abb_robot_driver_interfaces#9 solves your build issues? Or at least this build issue? |
|
Both changes were necessary for the After fixing this, the build failed further down the line: in the This is the error in the terminal after running Click to expandAfter running Click to expandIs this some sort of syntax error in one of the files? |
No, not really. This is a problem with The error is this (from here): enum class SwitchState
{
DONE,
ONGOING,
ERROR
};
(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 |
|
@traversaro would perhaps have run into this problem with |
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.
Regarding compiling the driver, then I just downloaded the driver packages and build them with |
I never used |
|
@traversaro wrote:
ms-iot/ROSOnWindows#294 (comment), hmm? :)
hm, annoying. And it's also not here, but in Note: this is not |
Quoting for the issue:
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. |
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 #17 (comment) :( Edit: and confusingly @jontje doesn't run into the problem: #17 (comment). |
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:
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.
None of the installed packages (as listed here) in my The next step as I understand will be to search for a file that has |
|
@dyumanaditya wrote:
perhaps the fact that
Not "with ROS". Perhaps with "ROS Noetic as ported and distributed by MS".
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 |
|
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. |
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 |
|
@dyumanaditya wrote:
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:
@dyumanaditya: could you try this? |
|
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 |
|
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 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 #17 (comment) somewhere in |
|
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. |
|
|
It looks like ERROR is used both in the @ooeygui, thoughts? |
|
@gavanderhoorn We have put in |
|
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
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA24PYMYIG2G7F7DEOW7PXTTDET75ANCNFSM4YS7D4WA>
.
|
|
@bmagyar wrote:
depending on your perspective, the offending header would be one of the core Windows headers, or the one in 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 ros-controls/ros_control#492 I found ros-controls/ros_control#397, that seems to be related to this discussion. |
|
Thanks for that. The fix in ros-simulation/gazebo_ros_pkgs#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 |
|
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 |
|
Thank you @traversaro, this fix the problem! |
* Update conda_forge_pinnings.yaml * Update pinnings * Bump build numbers * Build requested packages * Fixup * No need for opencv pinning anymore * Old ogre for noetic * Sync with humble * Fix * Fix * Sync * full_rebuild=true * Update run_constraints * Fixup rviz patch * Update vinca_linux_aarch64.yaml * Update vinca_osx_arm64.yaml * Update vinca_win.yaml * pcl 1.12.1 * qt 5.15 * Fixup qt-main for linux * Add -DNOGDI to Windows build or RViz (#296) To avoid #295 (comment), see ros-industrial/abb_robot_driver#17 (comment) . * Bump jackal packages, use now released noetic packages instead of melodic ones * Add libcurl mapping * Update patches * Actually rebuild all packages * Additional mappings * Fix qt-gui-cpp issues * Fixup * Fixup again * Last remaining qt-gui-cpp fixes * Fix rviz on Linux, rtabmap does not currently work due to mismatched migrations re boost and vtk * Fixes for rviz * Progress toward rviz * rviz debug * rviz finally working locally * Fixup patch on win * doxygen wants dot (graphviz) * linux-64 complete now ;) * fixup robot-locatization win patch * Create ros-noetic-eigenpy.patch * Update ros-noetic-eigenpy.patch * Update ros-noetic-eigenpy.patch * Update ros-noetic-eigenpy.patch * Simplify find python stuff * only eigenpy at the moment on aarch for faster debug * Simplify find python stuff * Add move-base to osx-arm64 * Update conda_forge_pinnings.yaml * Update conda_build_config.yaml * Boost 1.78 * mirror ros-humble changes * Try and de-vendor eigenpy * Unconditionally use sip5 .. * Sync with humble * Prepare building on robostack-staging channel Co-authored-by: Silvio Traversaro <[email protected]>
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
And this is my CMakeOutput log:
Click to expand
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?
The text was updated successfully, but these errors were encountered: