docs: install_windows_src

[azeey-test]

Configuration

• buildType: Source
• os: Windows

Links

• Live
• Source

Process

Step 1 - Instructions work

Step 2 - Images (if there are any) match the result

[knmcguire]

I can try out this one 😄

[knmcguire]

Alright, I'm hitting 2 issues currently following the instructions:

1, Visual studio install
The visual studio community instructions don't fit with version 2022, namely check “MFC and ATL support”, and uncheck “C++ Cmake Tools.” We will install cmake via Conda. All other checkboxes can be left unchecked.

C++ Cmake tools is now called 'c++ Cmake tools for windows' and MFC and ATL are seperated in 'C++ ATL for latest ... build tools...' and 'C++ MFC for latest ... build tools...'. Also the sentence of '... can be left unchecked' almost made me remove all the other checkboxes. I have print screen here of what I selected according to my interpretation of those instructions:

But not sure if it is correct since that makes me go to the following:

2. Build issues.

gz-math doesn't build with colcon:

\gz-ws>colcon build --cmake-args -DBUILD_TESTING=OFF --merge-install --packages-up-to gz-sim9 gz-tools2
Starting >>> gz-cmake4
Finished <<< gz-cmake4 [11.8s]
Starting >>> gz-utils3
Starting >>> gz-tools2
Finished <<< gz-tools2 [13.9s]
Finished <<< gz-utils3 [24.1s]
Starting >>> gz-math8
Starting >>> gz-plugin3
Finished <<< gz-plugin3 [25.3s]
Failed   <<< gz-math8 [26.2s, exited with code 1]

Summary: 4 packages finished [1min 2s]
  1 package failed: gz-math8
  10 packages not processed
WNDPROC return value cannot be converted to LRESULT
TypeError: WPARAM is simple, so must be an int object (got NoneType)

Still in the process of figuring out what is necessary. Perhaps I have missed something with the visual studio install or I have to check if I can install 2019.

The debugging will continue...

[knmcguire]

Alright I've got more data here. The stdout_error of colcon for gz_math is indicating an issue with ruby:

...\miniconda3\envs\gz-ws\include\ruby-3.3.0\x64-mswin64_140\ruby\config.h(4,1): error C1189: #error:  MSC version unmatch: 1920..1939 is expected. [C:\Users\kimbe\Development\simulation\gazebo\gz-ws\build\gz-math8\src\ruby\rbmath.vcxproj]
  (compiling source file '../../lib/ruby/Vector3RUBY_wrap.cxx'

This looks like similarly to what openstudio is dealing with here: NREL/OpenStudio#5223.

I've downgraded the ruby package to 3.2.2 from 3.3.3 with conda install ruby==3.2.2 --channel conda-forge but still had the same issue, so currently investigating which version MSC fits with this version of conda (3.3.3) from visual studio install

[azeey]

So the issue is with building swig wrappers? You can disable them with a CMake argument -DSKIP_SWIG=ON.

[knmcguire]

Yes disabling that did work. I was hoping to find the right ruby version but couldn't manage to do that within an amount of time, or looking for the exact right MSC version.

Now I've hit gz-rendering issues when I build with:

colcon build --cmake-args -DBUILD_TESTING=OFF -DSKIP_SWIG=ON --merge-install --packages-up-to gz-sim9 gz-tools2

I get this error:

  Ogre2WireBox.cc
C:\Users\kimbe\Development\simulation\gazebo\gz-ws\src\gz-rendering\ogre2\src\Ogre2Scene.cc(700,5): error C2065: 'GLint': undeclared identifier [C:\Users\kimbe\Development\simulation\gazebo\gz-ws\build\gz-rendering9\ogre2\src\gz-rendering9-ogre2.vcxproj]
C:\Users\kimbe\Development\simulation\gazebo\gz-ws\src\gz-rendering\ogre2\src\Ogre2Scene.cc(700,11): error C2146: syntax error: missing ';' before identifier 'glMaxTexSize' [C:\Users\kimbe\Development\simulation\gazebo\gz-ws\build\gz-rendering9\ogre2\src\gz-rendering9-ogre2.vcxproj]
C:\Users\kimbe\Development\simulation\gazebo\gz-ws\src\gz-rendering\ogre2\src\Ogre2Scene.cc(700,11): error C2065: 'glMaxTexSize': undeclared identifier [C:\Users\kimbe\Development\simulation\gazebo\gz-ws\build\gz-rendering9\ogre2\src\gz-rendering9-ogre2.vcxproj]
C:\Users\kimbe\Development\simulation\gazebo\gz-ws\src\gz-rendering\ogre2\src\Ogre2Scene.cc(701,19): error C2065: 'GL_MAX_TEXTURE_SIZE': undeclared identifier [C:\Users\kimbe\Development\simulation\gazebo\gz-ws\build\gz-rendering9\ogre2\src\gz-rendering9-ogre2.vcxproj]
C:\Users\kimbe\Development\simulation\gazebo\gz-ws\src\gz-rendering\ogre2\src\Ogre2Scene.cc(701,41): error C2065: 'glMaxTexSize': undeclared identifier [C:\Users\kimbe\Development\simulation\gazebo\gz-ws\build\gz-rendering9\ogre2\src\gz-rendering9-ogre2.vcxproj]
C:\Users\kimbe\Development\simulation\gazebo\gz-ws\src\gz-rendering\ogre2\src\Ogre2Scene.cc(701,5): error C3861: 'glGetIntegerv': identifier not found [C:\Users\kimbe\Development\simulation\gazebo\gz-ws\build\gz-rendering9\ogre2\src\gz-rendering9-ogre2.vcxproj]
C:\Users\kimbe\Development\simulation\gazebo\gz-ws\src\gz-rendering\ogre2\src\Ogre2Scene.cc(706,35): error C2065: 'glMaxTexSize': undeclared identifier [C:\Users\kimbe\Development\simulation\gazebo\gz-ws\build\gz-rendering9\ogre2\src\gz-rendering9-ogre2.vcxproj]

I've added the -DGZ_RENDERING_HAVE_OGRE2=False or -DUSE_UNOFFICIAL_OGRE_VERSIONS=True to the build flags but that still caused the same error. I also got a warning that Ogre versions above 1.9 were unsupported (when I didn't include the second flag), but conda forge only has ogre 1.10 or higher.

[Sanjay1911]

I've the same error as well. Did you manage to solve this?

colcon build --cmake-args -DBUILD_TESTING=OFF -DSKIP_SWIG=ON --merge-install --packages-up-to gz-sim9 gz-tools2

Starting >>> gz-cmake4
Finished <<< gz-cmake4 [1.34s]
Starting >>> gz-utils3
Starting >>> gz-tools2
Finished <<< gz-tools2 [1.52s]
Finished <<< gz-utils3 [1.64s]
Starting >>> gz-math8
Starting >>> gz-plugin3
Finished <<< gz-math8 [1.58s]
Starting >>> gz-common6
Starting >>> gz-msgs11
Starting >>> sdformat15
Finished <<< gz-plugin3 [1.73s]
Finished <<< gz-common6 [2.17s]
Starting >>> gz-rendering9
Finished <<< gz-msgs11 [2.42s]
Starting >>> gz-transport14
Starting >>> gz-fuel_tools10
Finished <<< sdformat15 [2.92s]
Starting >>> gz-physics8
Finished <<< gz-physics8 [6.27s]
Failed <<< gz-rendering9 [7.25s, exited with code 1]
Aborted <<< gz-fuel_tools10 [9.25s]
Aborted <<< gz-transport14 [30.8s]

Summary: 9 packages finished [38.0s]
1 package failed: gz-rendering9
2 packages aborted: gz-fuel_tools10 gz-transport14
3 packages not processed
WNDPROC return value cannot be converted to LRESULT
TypeError: WPARAM is simple, so must be an int object (got NoneType)

[azeey]

I think this is a bug. I will work on a fix.

[azeey]

Fix in gazebosim/gz-rendering#1049

[knmcguire]

thanks @azeey! I've applied the fix and now it builds all.

I wish that was the end of it, but I got a backtrace when I sourced the terminal and ran gz sim -s.

Seems like it is going wrong with the gz-msgs but the build didn't show any particular issues.

DynamicFactory(): Unable to parse descriptor set from [C:/Users/kimbe/Development/simulation/gazebo/gz-ws/install\share\gz\protos\gz-msgs11.gz_desc]
Stack trace (most recent call last):
#25   Object "", at 00007FF93AD9257D, in BaseThreadInitThunk
Attempt to access invalid address.

#24   Object "", at 00007FF6AE291264, in  ??
Attempt to access invalid address.

#23   Object "", at 00007FF6AE29104A, in  ??
#22   Object "", at 00007FF8E5DF426A, in ruby_run_node
#21   Object "", at 00007FF8E5DF199B, in rb_ec_error_print
#20   Object "", at 00007FF8E5E08B26, in rb_vm_exec
#19   Object "", at 00007FF8E5E13FC0, in ruby_vm_special_exception_copy
#18   Object "", at 00007FF8E5E19412, in ruby_vm_special_exception_copy
#17   Object "", at 00007FF8E5E0DCCA, in ruby_vm_special_exception_copy
#16   Object "", at 00007FF8E5E0DBF8, in ruby_vm_special_exception_copy
#15   Object "", at 00007FF8E5E0DF7A, in ruby_vm_special_exception_copy
#14   Object "", at 00007FF92BBC34C9, in Init_fiddle
#13   Object "", at 00007FF8E5EAB51A, in rb_thread_call_without_gvl
#12   Object "", at 00007FF8E5EAA74A, in rb_nogvl
#11   Object "", at 00007FF92BBC3A2D, in Init_fiddle
#10   Object "", at 00007FF9293F4212, in ffi_call
#9    Object "", at 00007FF9293F4332, in ffi_call
#8    Object "", at 00007FF9293F4541, in ffi_call_win64
#7    Object "", at 00007FF918E9312F, in runServer
#6    Object "", at 00007FF8F6CD5BC1, in gz::common::Console::Init
#5    Object "", at 00007FF918531762, in gz::utils::log::v3::Logger::SetLogDestination
#4    Object "", at 00007FF8FF3EABD1, in spdlog::sinks::basic_file_sink<std::mutex>::basic_file_sink<std::mutex>
#3    Object "", at 00007FF8FF3EBEF0, in spdlog::details::file_helper::open
#2    Object "", at 00007FF8FF3E52B5, in spdlog::throw_spdlog_ex
#1    Object "", at 00007FF910205267, in CxxThrowException
#0    Object "", at 00007FF93A41FABC, in RaiseException

[azeey]

Thanks @knmcguire. The gz-msgs issue is different and is somewhat harmless. It also exists in Harmonic. The backtrace looks like it came from gz::common::Console which is now using spdlog, a new change in Ionic. I'll look into it some more.

[azeey]

@knmcguire Fix in gazebosim/gz-sim#2589

[knmcguire]

Success! ✅ Thanks a lot!

Other than the warning of the descriptor when opening up a VS studio command prompt with the conda environment activated, I managed to run the server in one terminal with gz sim -s and gz sim -g in the other. Here is a screenshot:

Other than the two fixes that you have already made a PR for @azeey, we should change the instructions to add the -
-DSKIP_SWIG=ON, but that's all right? Shall I make a PR for that?

[traversaro]

Yes disabling that did work. I was hoping to find the right ruby version but couldn't manage to do that within an amount of time, or looking for the exact right MSC version.

Sorry, I had missed this. conda-forge pins ruby to 2.* (see https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/dbebf7dbbd2d7720d5b83419b88293ccbc2a438d/recipe/conda_build_config.yaml#L824-L826), and the 3.1 migration quite stalled (see conda-forge/conda-forge-pinning-feedstock#4805). So just to play safe we could pin ruby to 2.* in the installation procedure (if it is easier then just disabling ruby bindings).

[knmcguire]

Ah yes perhaps. I'll try downgrading ruby first and see if it still builds. It does seem that many of the conda forge packages will be downgraded as well so just as a sanity check I'll try to clear the installs and build again. I'll let you know if there are any issues.

[knmcguire]

@traversaro I'm afraid that ruby 2.7 (so locking the conda package install to 2.*) still gave an error but now with a different MSC version

 MSC version unmatch: _MSC_VER: 1916 is expected.

seems like ruby is just a bit too picky, which is what I've seen on other forums of other projects... so I'm afraid that we really need to turn off the swig build here.

I've made a tiny PR to change the doc to include this: gazebosim/docs#497

[traversaro]

Ah! I reviewed a bit how we used ruby in conda-forge binaries, and indeed we never built ruby bindings, we just used ruby in the sdformat scripts. Indeed if no one ever used them it make sense to just skip ruby bindings on Windows, thanks for fixing the docs!

[Combuster54]

Those changes are available now? I would like to contribute on Windows

[knmcguire]

Yes the changes that @azeey made have been merged already so if you follow the install instructions those will work. My doc change PR hasn't been merged yet so when you come to the colcon build step use this:

colcon build --cmake-args -DBUILD_TESTING=OFF -DSKIP_SWIG=ON --merge-install --packages-up-to gz-sim9 gz-tools2

[avanmalleghem]

I run into the following issue when following your doc :

I'm on a windows server 2022

Can someone help me so that I can start working on windows issues ?

[knmcguire]

Isn't this because the windows server doesn't have any gpu access? It might be difficult to do the tutorials then actually

[avanmalleghem]

I added a GPU but still have the issue unfortunately...

[traversaro]

Can you open a new issue in gz-sim following the template and tag me there? Thanks!

[avanmalleghem]

Issue available here gazebosim/gz-sim#2620

[peci1]

Maybe this will save some time to others who have decided to put their conda env dir to the same directory level as src: gazebosim/docs#513 . In short, don't do it!

[peci1]

Some more Windows tips in gazebosim/docs#515 .