Home > database >  VCRUNTIME140_1D.dll missing in Visual Studio 2017 CMake project - do I need Visual Studio 2019 too a
VCRUNTIME140_1D.dll missing in Visual Studio 2017 CMake project - do I need Visual Studio 2019 too a

Time:10-19

Issue:

I've recently started developing (C ) on Win10. I have a CMake project that builds perfectly fine (both debug and release build), however if I try to run it with the intention of debugging, I get VCRUNTIME140_1D.dll missing error.

The issue lies in the absence of the debug version of the VC runtime 140.1 (hence the D prefix in the error message).

I start the binary in two ways:

  • PowerShell - where it silently crashes (it's a very typical uncooperative behaviour in PowerShell that I still need time to get used to)
  • Debugging mode in VS2017 - for the actual debugging. This is where the actual error (in the form of a message box) appears on my screen.

Setup:

Using Visual Studio 2017, Win10. Debugging is required during the development stage but later on a release build will be created and shipped to the customer.

Using CMake 3.12 (shipped with VS2017). Full CMakeLists.txt can be seen at the end.

The libraries I am linking against are

  • libtorch 1.12.1 - latest version of libtorch C binaries with dependencies (straight from the official website of PyTorch). Currently unable to identify compiler.
  • opencv 4.6.0 - latest version of OpenCV binaries (straight from the official website of OpenCV). Two versions available - VC14 and VC15. Using VC15, assuming that it refers to VC shipped with Visual Studio 2015, that is v140/v140.1 of the MSVC toolkit.

Both dependencies are available in debug and release versions. However I would like to (if possible) link against the release versions of the 3rd party libraries and concentrate on debugging my own code (the size of libtorch's debug build is insane - for both CPU and CUDA you get whopping 12GB!).

Ideas:

I looking on my C:\ and all I can find were

  • vcruntime140d.dll
  • vcruntime140.dll
  • vcruntime140_1.dll

I also read that /MD vs /MDd as flags play an important role.

I've encountered a couple of posts online mentioning that I need to install Visual Studio 2019.

Questions:

Following two questions are important here:

  • Which components do I need to install (VS2019 or otherwise) in order to obtain just this DLL and is it sufficient to have it in order to be able run in debug mode?

  • Can I use (for debugging only) a VC Runtime shipped with VS2019 Community Edition in a VS2017 Professional Edition project? Currently I have only access to the Pro version of VS2017.


My project file in CMake can be seen below:

CMakeLists.txt

cmake_minimum_required (VERSION 3.12 FATAL_ERROR)

project(pytroch
  DESCRIPTION "CMake example for PyTorch (libtorch C  ) integration"
  LANGUAGES CXX
)

set(CMAKE_CXX_STANDARD 14)

set(INCLUDE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/include")
set(SRC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/src")

set(CMAKE_PREFIX_PATH "${CMAKE_SOURCE_DIR}/deps/libtorch/1.12.1/debug/cpu/share/cmake/Torch")
#set(CMAKE_PREFIX_PATH "${CMAKE_SOURCE_DIR}/deps/libtorch/1.12.1/release/cpu/share/cmake/Torch")
find_package(Torch REQUIRED)
if(TORCH_FOUND)
    message(STATUS "Found Torch")
else()
    message(CRITICAL_ERROR "Unable to find Torch")
endif(TORCH_FOUND)

set(CMAKE_PREFIX_PATH "${CMAKE_SOURCE_DIR}/deps/opencv/4.6.0/")
find_package(OpenCV 4.6.0 REQUIRED)

add_library(pytorch_cv_utils SHARED "${SRC_DIR}/pytorch_cv_utils.cpp")
target_include_directories(pytorch_cv_utils PUBLIC  ${INCLUDE_DIR} ${TORCH_INCLUDE_DIRS} ${OpenCV_INCLUDE_DIRS})
target_link_libraries(pytorch_cv_utils PUBLIC ${TORCH_LIBRARIES} ${OpenCV_LIBS})

add_executable(pytroch_load_model
    "${SRC_DIR}/pytroch_load_model.cpp"
)
target_include_directories(pytorch_cv_utils PUBLIC  ${INCLUDE_DIR} ${TORCH_INCLUDE_DIRS})
target_link_libraries(pytroch_load_model PRIVATE pytorch_cv_utils)

# Copy Torch dependencies to binary folder
file(GLOB LIBTORCH_DLLS
#  "${CMAKE_SOURCE_DIR}/deps/libtorch/1.12.1/release/cpu/lib/*.dll"
  "${CMAKE_SOURCE_DIR}/deps/libtorch/1.12.1/debug/cpu/lib/*.dll"
)
file(COPY
    ${LIBTORCH_DLLS}
    DESTINATION "${CMAKE_BINARY_DIR}/bin/"
)

# Copy OpenCV dependencies to binary folder
file(GLOB OPENCV_DLLS
  "${CMAKE_SOURCE_DIR}/deps/opencv/4.6.0/x64/vc15/bin/*.dll"
)
file(COPY
    ${OPENCV_DLLS}
    DESTINATION "${CMAKE_BINARY_DIR}/bin/"
)

CodePudding user response:

"Using VC15, assuming that it refers to VC shipped with Visual Studio 2015".

No, that would be wrong. Visual Studio 2015 shipped with Visual C version 14. Visual C 15 shipped with VS2017, VC16 with VS2019 and VC17 with VS2022.

The mixup here is between VC sequential version numbers and Visual Studio years. Visual C was already up to version 6 when C was standardized in 1998. But there is less then one release per calendar year - 11 releases in 24 years.

CodePudding user response:

The current generation of the Microsoft Visual C/C Runtime has binary compatibility for VS 2015 Update 3, VS 2017, VS 2019, and VS 2022. This means that a newer version of the DLLs works with libraries and executables built with older versions of this tool series.

For retail distribution (i.e. just the Release versions) you have a few options as noted Microsoft Docs. You can obtain the latest REDIST packages from here: X64, X86, and ARM64.

The DEBUG versions of the CRT binaries are only available with Visual Studio, but you can use the VS 2019 or VS 2022 Build Tools Edition to obtain them.

Whether or not you can use the VS Community Edition depends on your situation. The feature set is identical to VS Professional, but you need to meet the requirements of the license agreement.

CodePudding user response:

Installing VS2019 solved the issue. I am still using VS2017 but now the vcruntime140_1d.dll is found alongside the rest. Final product will of course not ship with any debug version dependencies and only a release version will be given to the customer.

I will open a new question regarding licensing issues when combining debug library shipped with community edition with a professional edition project for commercial applications.

I am not sure as to why Microsoft has decided to make a debug version of the runtime for something that came out in 2015 available in a 2019 edition but not in the 2017 one.

  • Related