Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: install_windows_src #1701

Closed
azeey-test opened this issue Aug 29, 2024 · 25 comments · Fixed by gazebosim/gz-sim#2589 or gazebosim/gz-utils#145
Closed

docs: install_windows_src #1701

azeey-test opened this issue Aug 29, 2024 · 25 comments · Fixed by gazebosim/gz-sim#2589 or gazebosim/gz-utils#145

Comments

@azeey-test
Copy link
Collaborator

Configuration

  • buildType: Source
  • os: Windows

Links

Process

Step 1 - Instructions work

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

@knmcguire
Copy link

I can try out this one 😄

@knmcguire
Copy link

knmcguire commented Aug 29, 2024

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:

Screenshot 2024-08-29 200233

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
Copy link

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
Copy link
Contributor

azeey commented Aug 29, 2024

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

@knmcguire
Copy link

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
Copy link

Sanjay1911 commented Aug 30, 2024

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
Copy link
Contributor

azeey commented Aug 30, 2024

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

@azeey
Copy link
Contributor

azeey commented Aug 31, 2024

Fix in gazebosim/gz-rendering#1049

@knmcguire
Copy link

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
Copy link
Contributor

azeey commented Sep 3, 2024

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
Copy link
Contributor

azeey commented Sep 4, 2024

@knmcguire Fix in gazebosim/gz-sim#2589

@knmcguire
Copy link

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:

image

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
Copy link

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
Copy link

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
Copy link

@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
Copy link

traversaro commented Sep 4, 2024

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
Copy link

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

@knmcguire
Copy link

knmcguire commented Sep 5, 2024

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
Copy link

avanmalleghem commented Sep 12, 2024

I run into the following issue when following your doc :
image
I'm on a windows server 2022

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

@knmcguire
Copy link

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

@avanmalleghem
Copy link

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

@traversaro
Copy link

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

@avanmalleghem
Copy link

avanmalleghem commented Sep 12, 2024

Issue available here gazebosim/gz-sim#2620

@peci1
Copy link

peci1 commented Sep 14, 2024

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
Copy link

peci1 commented Sep 15, 2024

Some more Windows tips in gazebosim/docs#515 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment