22

I'm getting intermitting 'fatal error: ... file not found' errors building C++ application using either gcc 4.8 or clang 3.8 under Ubuntu 16.04.2 running in Windows Subsystem for Linux (WSL), when including C++ header files, but only since installing the Windows 10 April update (Version 1803, OS Build 17134.1) a few days ago.

Example error message from clang compiler:

fatal error: 'boost/preprocessor/list/fold_left.hpp' file not found

Example error message from gcc compiler:

fatal error: boost/mpl/aux_/at_impl.hpp: No such file or directory

I say the error is intermittent because if I re-run the build, the particular error that interrupted the build disappears, and the build runs for a while longer until it either builds successfully or randomly fails to include some other file with the same kind of 'file not found' error.

The timing of this fault and the randomness of it make me suspect it is a new bug in WSL. Anyone else seeing this or have suggestions on how to fix it?

The error is not always in a Boost include, but often is simply because Boost comprises a large proportion of the overall include files. The files being built exist on a shared volume under /mnt/d/.

Andrew Medlin
  • 461
  • 3
  • 11
  • Can you describe the specifics of the shared volume? – sehe May 07 '18 at 22:16
  • 1
    The shared volume is a 1 TB SSD formatted as NTFS, mounted as D: drive in Windows 10. My PC's C: and D: drive appear in the Ubuntu installation under the path /mnt/c and /mnt/d respectively. Remember this all worked find until the Windows 10 update. – Andrew Medlin May 07 '18 at 23:55
  • 1
    I tried completely uninstalling and reinstalling WSL with the latest from the Windows Store, and setting up my WSL Ubuntu from scratch, but the problem remains. – Andrew Medlin May 09 '18 at 00:50
  • 1
    Just grabbed latest patch, now on Windows 10 OS Build 17134.48 (documented here [https://support.microsoft.com/en-us/help/4103721/windows-10-update-kb4103721]), but this did not resolve the problem. – Andrew Medlin May 10 '18 at 03:43
  • 1
    I have the same issue, just one SSD drive on this machine, accessing files through /mnt/c .. I'm doing rather large compiles and it seems to be a random file (usually a commonly used header) that's "missing". – Jari Komppa May 15 '18 at 10:39
  • I tried to make a trivial repro for this bug by compiling a single file over and over again, but that doesn't seem to trigger it. Most likely requires either multithreading or otherwise opening a lot of files in a short timespan. (For what it's worth, this machine has x64 win10 pro) – Jari Komppa May 15 '18 at 11:19
  • @jari, what exactly is your windows 10 version? It displays this on the first line of a command line window. (Run 'cmd') – Andrew Medlin May 15 '18 at 22:30
  • More details of the drives. Both my SSDs are Samsung 850 EVO 1 TB. They are attached to SATA bus 0 and bus 3. In my BIOS settings, my SATA Controller is set to RAID mode. Other options are ATA and AHCI. The PC is a Dell Optiplex 9020 with model 06X1TJ model motherboard, Haswell chipset, and Core i7 4790 CPU. It may be fruitful for others having this problem to check these settings to see if we have something in common. – Andrew Medlin May 15 '18 at 23:21
  • I changed my SATA controller mode from RAID to AHCI, but this did not fix the problem. – Andrew Medlin May 15 '18 at 23:46
  • My windows version is 10.0.17134.48 – Jari Komppa May 16 '18 at 06:18
  • 1
    I have the same problem and have filed an issue on the WSL issue tracker on Github. For me the problem only appears for files stored on the DrvFs. https://github.com/Microsoft/WSL/issues/3204 – P.G. May 16 '18 at 09:50
  • According to that issue tracker this is already fixed in a future version. Any idea what schedule those get sent to end users (as in not preview versions)? Sometime next fall? =) – Jari Komppa May 16 '18 at 11:14
  • 2
    Yes. Every 176xx fix will be released for everyone in Fall 2018 Update. – onoma May 17 '18 at 00:47

3 Answers3

17

This has been identified as a multithreading bug (https://learn.microsoft.com/en-us/windows/wsl/release-notes#build-17655-skip-ahead) and should get fixed in a future windows update.

Since it's a multithreading bug, it might be possible to work around it by not using multithreaded builds.

If in a hurry, it might be possible to just get to the windows insider program and use one of the preview builds.

Jari Komppa
  • 584
  • 4
  • 20
0

In my case, it was not multi-threading but the path to the toolchain. The failed case was: toolchain was installed in /mnt/c/.../tools/ A good case was: toolchain was installed in /home/yurir/tools/

I guess the mapping of windows folders with ubuntu folders creates some mess.

Ivan Aracki
  • 4,861
  • 11
  • 59
  • 73
yurir
  • 21
  • 3
0

Why this happens:

This intermittent issue could be a result of something called the Fast Boot for Windows. This setting is on by default on Windows 10: on shutdown or reboot Windows simply reloads the C:\hiberfile.sys image and then locks its drive partitions for security. (Making changes to your NTFS partition while it is hibernated is risky. Because of this the WSL tool that mounts the partition will not mount it in Read/Write mode, if it sees the hibernation flag.)

To Fix:

Goto Control Panel > Hardware and Sounds > Power Options > Find a setting for "Turn on fast Startup" and uncheck the option. Restart your computer and you should have access to the disk.

Nitin Nain
  • 5,113
  • 1
  • 37
  • 51