У меня есть простые CMakeLists для составления объездных экспресс
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)
Необходимые флаги установлены в верхнем уровне CMakeLists
add_definitions(-DDETOURS_X86 -DDETOURS_32BIT)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /FS")
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /FS")
Тем не менее, при попытке скомпилировать отладочную сборку каждый файл .cpp после detours.cpp
бросает
СБОЙ: 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: фатальная ошибка C1041: невозможно открыть базу данных программы ‘z: \ repo \ src \ ext \ detours_express_3.0 \ src \ cmakefiles \ detours.dir \ vc120.pdb’; если несколько файлов CL.EXE записывают в один и тот же файл .PDB, используйте / FS
Если я перезапущу ninja detours
затем то же самое происходит со следующими 3 файлами cpp, затем со следующими 2, затем последними, затем проект полностью компилируется.
Если я бегу ninja -j1 detours
тогда нет никаких проблем, так как я просто отключил параллельные сборки.
Почему он игнорирует мой параметр / FS?
Я использую Visual Studio 2013.
Обновление 1
Это внутри виртуальной машины в Virtualbox 4.3.10 с гостевыми дополнениями. Z: \ — это общая папка, которую я смонтировал.
Я обязательно отключил Защитник Windows на ВМ и хосте и удалил сторонний AV на хосте.
Обновление 2
Я нашел обходной путь, который избегает симптомов, и добавил его в качестве ответа, но он все еще не объясняет, почему /FS
на самом деле не синхронизирует замки.
Не столько решение, сколько обходной путь. Похоже, что механизм, который VirtualBox использует для реализации общих папок, является виновником. Я заменил общую папку виртуальной коробки на общую папку Windows, и я больше не получаю эти ошибки.
Странно, что последовательные сборки не вызывают этих ошибок, возможно, компиляция первого файла вызывает синхронизацию, которая предотвращает блокировку других файлов, пока она не будет завершена, и, поскольку сборка выполняется параллельно, другие файлы .cpp запускаются в блокировку. Я не уверен, что это вина VirtualBox или MSVC, так как это похоже на проблему, которая /FS
должен исправить.
меры
Других решений пока нет …