WSL Linux Builds

[kellac1]

Hi,

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=Debug

I do not see the LinuxAppLauncher being called in the VisualGDB Diagnostics Console.

Any help would be appreciated,

Chris

• This topic was modified 1 month, 1 week ago by kellac1.

[support]

Hi,

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.

[kellac1]

Running that gives the following output.

Connecting to port 55932…
Launching uname, pty=5…
argv[0] = uname
argv[1] = -a

DISPLAY = :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] = -a

DISPLAY = :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,

[support]

Yes, 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.

[kellac1]

That seems to have solved it. We made the build command require sudo. Removing that it works just fine. Thank you for the help.

[Author]

Posts