I am writing client-server aplication which exchange OpenCL functions and execute them on server. However I can not link OpenCL properly. Program compiles but on run shows 0xc000007b
error.
Visual Studio 15 2017
x64
x64
and before linking OpenCL
worked flawlessly.Intel SDK platform
(newest).cl.h
header, link with CMake
, and don't use any OpenCL
function, everything works.I know that error code 0xc000007b
is caused by loading x32 dlls into x64 project, however I don't think it is an issue here.
Main CMake:
find_package(OpenCL REQUIRED)
# include directories
include_directories(${OpenCL_INCLUDE_DIRS})
message(STATUS "opencl_include: " ${OpenCL_INCLUDE_DIRS})
# link libraries
link_directories(${OpenCL_LIBRARIES})
message(STATUS "opencl_lib: " ${OpenCL_LIBRARIES})
Server CMake:
add_executable(server ${SRC_HEADERS} ${SRC})
target_link_libraries(server
${OpenCL_LIBRARY}
)
CMake output:
opencl_include: C:/Intel/OpenCL/sdk/include
opencl_lib: C:/Intel/OpenCL/sdk/lib/x64/OpenCL.lib
In Build/bin/Debug
catalog OpenCL.dll is created properly. I have tried coppying files into source directory, linking it by hand in cmake and setting properties in Visual Studio instead of cmake. Still same issue.
I've shortened code to show only important parts, if I've missed anything relevant let me know, I will include it into my question.
EDIT:
I've also tried to link x86 OpenCL.lib version, in that case there is a compile error:
unresolved external symbols
There could be several reasons for the error, but to start troubleshooting, you can verify the following:
1) Whether you actually built a 64-bit DLL and not a 32-bit DLL, and
2) Windows itself is actually loading your 64-bit DLL at runtime, and not a 32-bit DLL that happens to have the same file name as the 64-bit DLL.
For 1), you can use dumpbin
, or a utility such as Dependency Walker to verify that the DLL being build is 64 bit.
If after applying step 1), you have verified that the DLL is 64-bit, step 2) is the next thing to verify. Since you mentioned in the comments that you have verified the DLL being built is 64-bit, then you should try step 2).
For step 2), when Windows attempts to load a DLL at runtime, the first name that Windows encounters that matches the DLL file name will be loaded, regardless if it is the right DLL or not in terms of bitness level. The issue comes when there are 2 (or more) DLL's with the same exact name, but have differing "bitness" levels, i.e. 32-bit or 64-bit than the application.
If you're running a 64-bit application and Windows tries to load a 32-bit DLL, then you will get the 0xc0000007b
error -- the same vice-versa, where loading a 64-bit DLL into a 32-bit application causes the same issue to occur.
This link describes the search logic that Windows uses when loading DLL's. Make sure that Windows is not inadvertently picking up a DLL that matches the name, but not the same application bit-level.
For most non-trivial situations, this error will be one where the incorrect DLL is found on the system path and thus Windows attempts to load it. But as the link suggests, there are other scenarios that would cause Windows to pick a DLL (too numerous to mention, so look at the posted link).
Unfortunately this is how Windows works, so be careful when you have both 32 and 64-bit versions of a DLL with the same name, and the potential for one or the other to get loaded by Windows is a possibility.
User contributions licensed under CC BY-SA 3.0