You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Warning: Path is not a file: AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\usr\bin\gcc, despite IntelliSense working #3825
Other extensions you installed (and if the issue persists after disabling them): None
I'm getting this warning when trying to set "compilerPath": "/usr/bin/gcc":
Path is not a file: "C:\Users\felix\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\usr\bin\gcc".
The warning is actually incorrect: This file exists, and IntelliSense works fine. If I remove "compilerPath": "/usr/bin/gcc" from my configuration, IntelliSense no longer works, and I get build errors, so the configuration is used despite this warning.
To Reproduce
I'm pretty sure these steps don't suffice, but here's what I did:
I don't repro this problem, with Ubuntu or Ubuntu 18.04. The only way I was able to repro it was when I did not have gcc installed. Can you run the C/C++: Log Diagnostics command to see what gcc path it is using when you use the "/usr/bin/gcc"?
That output looks correct. Hmm, not sure why the config squiggle would appear, but you could get the incorrect squiggle to go away via "enableConfigurationSquiggles": false in the root (or the matching C_Cpp.default.enableConfigurationSquiggles setting).
While I don't know the internals, I find it really suspicious that I configure /usr/bin/gcc, and the debug output lists /usr/bin/gcc, but the squiggle complains about the Windows version of that path.
The code that implements this squiggle is in our open source TypeScript, so theoretically you could debug it to see why it's failing for you if you use the "release" branch. The code runs on Windows so we need to convert the path to the Windows path, which appears to work successfully, so I don't know why it would fail to be found.
Hm, OK. Another thought: While the file does exist, it's a 0-byte file, because it's a symbolic link on the Linux side. Maybe this is tripping something up?
That should still work. It's a symbolic link to gcc-7 for me as well. The only case it would fail is if there was a symbolic link in the WSL version of the path that we would need to translate on the WSL side in order to get the correct Windows path. Your OS matches mine as well, so I don't know what is different that could be causing the failure.
Oh, wait, it shouldn't be 0 bytes -- are you sure it's really 0 bytes? Size on Disk can be 0 bytes, but it should contain text when opened in notepad (i.e. Size not 0).
Activity
sean-mcmanus commentedon Jun 25, 2019
I don't repro this problem, with Ubuntu or Ubuntu 18.04. The only way I was able to repro it was when I did not have gcc installed. Can you run the C/C++: Log Diagnostics command to see what gcc path it is using when you use the "/usr/bin/gcc"?
fefrei commentedon Jun 25, 2019
This is the output (with a configuration that also has some
includePathentries, previously omitted because the problem happened without them):sean-mcmanus commentedon Jun 25, 2019
That output looks correct. Hmm, not sure why the config squiggle would appear, but you could get the incorrect squiggle to go away via
"enableConfigurationSquiggles": falsein the root (or the matching C_Cpp.default.enableConfigurationSquiggles setting).Michelle Matias (@michelleangela) Colen Garoutte-Carson (@Colengms) Any ideas how this incorrect squiggle could occur or are you able to repro it?
fefrei commentedon Jun 25, 2019
While I don't know the internals, I find it really suspicious that I configure
/usr/bin/gcc, and the debug output lists/usr/bin/gcc, but the squiggle complains about the Windows version of that path.sean-mcmanus commentedon Jun 25, 2019
The code that implements this squiggle is in our open source TypeScript, so theoretically you could debug it to see why it's failing for you if you use the "release" branch. The code runs on Windows so we need to convert the path to the Windows path, which appears to work successfully, so I don't know why it would fail to be found.
fefrei commentedon Jun 25, 2019
Hm, OK. Another thought: While the file does exist, it's a 0-byte file, because it's a symbolic link on the Linux side. Maybe this is tripping something up?
sean-mcmanus commentedon Jun 25, 2019
That should still work. It's a symbolic link to gcc-7 for me as well. The only case it would fail is if there was a symbolic link in the WSL version of the path that we would need to translate on the WSL side in order to get the correct Windows path. Your OS matches mine as well, so I don't know what is different that could be causing the failure.
sean-mcmanus commentedon Jun 25, 2019
Oh, wait, it shouldn't be 0 bytes -- are you sure it's really 0 bytes? Size on Disk can be 0 bytes, but it should contain text when opened in notepad (i.e. Size not 0).
fefrei commentedon Jun 25, 2019
It appears to have 0 bytes:
And – suspiciously – Notepad cannot touch it:
However, the files look fine with WSL goggles on:
sean-mcmanus commentedon Jun 25, 2019
It might be because you upgraded to the "WslFs file system format"...I'm checking that out now...
sean-mcmanus commentedon Jun 25, 2019
I reproed it -- the WslFs file system format is the cause.
bobbrow commentedon Feb 5, 2020
Can you try using the Remote-WSL extension? We're not likely to make any changes to our WSL support now that that extension exists.
fefrei commentedon Feb 6, 2020
I’m using that right now, currently without issues. Thanks!