Sysprogs forums › Forums › VisualGDB › WSL Linux Builds
- This topic has 4 replies, 2 voices, and was last updated 1 year ago by
kellac1.
-
AuthorPosts
-
November 12, 2024 at 13:03 #36118
kellac1
ParticipantHi,
It seems like I am unable to build my linux app using WSL2. I have tried to follow these instructions (Troubleshooting Windows Subsystem For Linux (WSL) – VisualGDB Documentation), but still seems to hang on building. It is hanging on the following:
Run “sudo make CONFIG=Debug” in directory “/mnt/d/source/repos/XXXXx/XXX” on (Windows 10 Linux subsystem)
sudo make CONFIG=DebugI do not see the LinuxAppLauncher being called in the VisualGDB Diagnostics Console.
Any help would be appreciated,
Chris
-
This topic was modified 1 year ago by
kellac1.
November 13, 2024 at 21:17 #36120support
KeymasterHi,
VisualGDB handles WSL by launching a monitor process on the Linux side that forwards the actual application output back Windows via TCP. The most likely explanation why it’s not working is that the firewall either on Linux or Windows side is preventing VisualGDB from connecting to it.
If turning the firewall off doesn’t work, you can try narrowing it down by running VisualGDB.exe /lxsstest. It will run the “uname -a” command inside WSL, but will launch the monitor process in a separate window, so you can check if it does anything suspicious.
November 14, 2024 at 06:21 #36127kellac1
ParticipantRunning that gives the following output.
Connecting to port 55932…
Launching uname, pty=5…
argv[0] = uname
argv[1] = -aDISPLAY = :10
Waiting for the target process PID…
Target process PID: 7096
Forwarding output…
..Reporting exit code (0)
+[0]
Connecting to port 55933…
Launching uname, pty=5…
argv[0] = uname
argv[1] = -aDISPLAY = :10
Waiting for the target process PID…
Target process PID: 7101
Forwarding output…
..Reporting exit code (0)…
This keeps running for a while and incrementing the ports. Does this indicate it is working?
Thank you,
November 14, 2024 at 16:40 #36137support
KeymasterYes, this means it is working correctly.
On a second thought, do you have the “sudo” explicitly specified as the build command? If yes, it actually won’t work unless sudo is configured to run without asking for password for this user.
When VisualGDB decides to use sudo (there’s an option to enable it for debugging, but not for building), it uses special workarounds to handle sudo prompts, that won’t work if you just specify “sudo” as a part of the command line.
November 15, 2024 at 09:41 #36141kellac1
ParticipantThat seems to have solved it. We made the build command require sudo. Removing that it works just fine. Thank you for the help.
-
This topic was modified 1 year ago by
-
AuthorPosts
- You must be logged in to reply to this topic.