- This topic has 1 reply, 2 voices, and was last updated 1 hour, 28 minutes ago by
.
-
Posts
-
Hi!
Just spent last couple of hours chasing this down in one of my old projects where I use batch build file for Windows and Linux platform and WSL for Linux build.
Whatever I did from IDE build was successful, but from command line it didn’t seem to want to “talk to” WSL, while I was checking some other options in VisualGDB settings saw this one as the last one in the list “Use optimized WSL interface”, turned it off and like magic the old build script started working again!
Now this was my solution, maybe I missed something else?
Re, Uros
Hi,
The optimized WSL backend relies on wsl.exe executable to run WSL commands. E.g. “wsl gcc test.c” would normally just run gcc to compile test.c.
This used to be broken several Windows releases ago, where WSL would randomly hang, so VisualGDB used a much more complicated way to launch commands: it would run a special launcher inside WSL, that would accept a connection via TCP, and would forward the output there. However, this was causing problems with some users’ firewall setups or custom IP address configurations.
So, recently we added an option to use wsl.exe directly again, as the previous bugs we encountered with it appeared to be fixed. We are not aware of any issues with command-line builds. It could be another bug in wsl.exe, or something caused by a particular configuration. If you can narrow it down to a particular wsl.exe scenario, we can try adding a workaround on our side. However, it could be a much easier and safer bet to revert to the “heavy” network-based launching mode.
- You must be logged in to reply to this topic.