0
votes

I have a simple CMakeLists to compile detours express

project(detours)
add_library(detours STATIC detours.cpp disasm.cpp image.cpp modules.cpp creatwth.cpp)
file(COPY detours.h detver.h DESTINATION ${CMAKE_BINARY_DIR}/include)

The necessary flags are set in an upper level CMakeLists

add_definitions(-DDETOURS_X86 -DDETOURS_32BIT)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /FS")
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /FS")

Yet when trying to compile a debug build each .cpp file after detours.cpp throws

FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /TP -DDETOURS_32BIT -DDETOURS_X86 -Iinclude /DWIN32 /D_WINDOWS /W3 /GR /EHsc /FS /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /Foext\detours_express_3.0\src\CMakeFiles\detours.dir\modules.cpp.obj \Fdext\detours_express_3.0\src\CMakeFiles\detours.dir\ /FS -c ..\ext\detours_express_3.0\src\modules.cpp ..\ext\detours_express_3.0\src\modules.cpp : fatal error C1041: cannot open program database 'z:\repo\src\ext\detours_express_3.0\src\cmakefiles\detours.dir\vc120.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS

If I re-run ninja detours then the same happens with the next 3 cpp files, then the next 2, then the last, then the project is fully compiled.

If I run ninja -j1 detours then there are no issues, since I just disabled parrallel builds.

Why does it seem to be ignoring my /FS option? I'm using Visual Studio 2013.

Update 1

This is inside a VM in Virtualbox 4.3.10 with Guest Additions. Z:\ is a shared folder that I mounted. I've made sure to disable Windows Defender in the VM and the host, and uninstalled the third-party AV on the host.

Update 2

I found a workaround that avoids the symptoms and added it as an answer, but it still doesn't explain why /FS isn't actually synchronizing the locks.

1
Looks like CMake is unrelated here, as it adds /FS flag automatically (just before -c). Similar question: stackoverflow.com/questions/20643370/…. Probably, some external process locks your .pdb file. What kind of drive is Z:/? - Tsyvarev
Yeah, I noticed the /FS but figured I'd add it as a sanity check. I've poked through those solutions. It looks like each project already has an intermediate dir of it's own, detours.dir for example, and in this case I'm only compiling one project. It looks like the .cpp files are fighting over the .pdb, which would make sense since they'll all belong to the same executable later. I've tried searching for handles with ProcessExplorer while compiling but haven't had luck yet. - clark

1 Answers

0
votes

Not so much a solution as a workaround. It appears that whatever mechanism VirtualBox uses to implement shared folders is the culprit. I replaced the virtual box shared folder with a windows shared folder and I am no longer getting these errors.

It's strange that sequential builds don't cause these errors, perhaps compiling the first file causes a sync that prevents the other files from locking until it's done, and since the build is parallel the other .cpp files run into the lock. I'm not sure if this is VirtualBox's or MSVC's fault, though, since this seems like the kind of problem that /FS is supposed to fix.

Steps

  1. Disconnect network map from within VM
  2. Remove shared folder from VirtualBox settings
  3. Setup a Windows Share on host (Right click folder -> Share)
  4. Map this share in the VM