OpenCL 在调用 clGetPlatformIDs 时崩溃

我是 OpenCL 新手。在配备 Intel(R) HD Graphics 4000、运行 Windows 7 的 Core i5 计算机上工作。我安装了支持 OpenCL 的最新 Intel 驱动程序。 GpuCapsViewer 确认我有 OpenCL 支持设置。我使用 Intel OpenCL SDK 开发了一个简单的 HelloWorld 程序。我成功编译了该程序，但在运行时，它在调用 clGetPlatformIDs() 时崩溃并出现分段错误。这是我的代码：

#include <iostream>
#include <CL/opencl.h>

int main() {
    std::cout << "Test OCL  without driver" << std::endl;

    cl_int err;
    cl_uint num_platforms;

    err = clGetPlatformIDs(0, NULL, &num_platforms);
    if (err == CL_SUCCESS) {
        std::cout << "Success. Platforms available: " << num_platforms
                << std::endl;
    } else {
        std::cout << "Error. Platforms available: " << num_platforms
                << std::endl;
    }

    std::cout << "Test OCL without driver" << std::endl;
    std::cout << "Press button to exit." << std::endl;
    std::cin.get();
    return 0;
}

为什么 GpuCapsViewer 成功确认了 OpenCL 支持并可以使用它来运行其演示，但我无法运行我的代码？两者一定使用相同的功能，对吗？

已经为此工作好几天了。甚至尝试重新安装驱动程序。有任何想法吗？

Gpu Caps Viewer 说：

驱动程序：R295.93 (r295_00-233) / 10.18.10.3496 (3-11-2014)
OPENGL：OpenGL 4.2（GeForce GT 630M/PCIe/SSE2，带 290 个扩展）
OPENCL：OpenCL 1.1，GeForce GT 630M 计算单元：2@950MHz
CUDA：GeForce GT 630M CC：2.1，多处理器：2@950MHz
PHYSX：GPU PhysX (NVIDIA GeForce GT 630M)
多 GPU：不支持多 GPU（2 个物理 GPU）

UPDATE:

编译行：

g++ -I"C:\Program Files (x86)\Intel\OpenCL SDK\4.4\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"Test3.d" -MT"Test3.d" -o "Test3.o" "../Test3.cpp"
Finished building: ../Test3.cpp

链接器线：

g++ -L"C:\Program Files (x86)\Intel\OpenCL SDK\4.4\lib\x64" -o "TestOpenCL"  ./HelloWorld.o ./HelloWorld2.o ./Test3.o   -lOpenCL
Finished building target: TestOpenCL

操作系统：Windows 7 Ultimate 版本 6.1（内部版本 7601：Service Pack 1）

更新2，崩溃信息：

Problem Event Name: APPCRASH
Application Name:   TestOpenCL.exe
Application Version:    0.0.0.0
Application Timestamp:  53bc6ac5
Fault Module Name:  TestOpenCL.exe
Fault Module Version:   0.0.0.0
Fault Module Timestamp: 53bc6ac5
Exception Code: c0000005
Exception Offset:   0000000000002cc0
OS Version: 6.1.7601.2.1.0.256.1
Locale ID:  1033
Additional Information 1:   56e3
Additional Information 2:   56e3743a8a234df3bdeba0b507471c44
Additional Information 3:   8fe0
Additional Information 4:   8fe0ef5706153941955de850e5612393

更新3：

使用 DependencyWalker(http://dependencywalker.com/ http://dependencywalker.com/）作为转储箱的替代品。它会生成以下警告：

Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

这些警告似乎涉及以下 DLL，这些 DLL 均标有“打开文件时出错。系统找不到指定的文件(2)”错误消息。

API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
IESHIMS.DLL

更新 4，GDB 回溯：

Program received signal SIGSEGV, Segmentation fault.
0x0000000000402cc0 in clGetPlatformIDs ()
(gdb) backtrace full
#0  0x0000000000402cc0 in clGetPlatformIDs ()
No symbol table info available.
#1  0x0000000000402af3 in main () at ../Test3.cpp:11
        err = 0
        num_platforms = 0
        platform = 0x0

(gdb) backtrace
#0  0x0000000000402cc0 in clGetPlatformIDs ()
#1  0x0000000000402af3 in main () at ../Test3.cpp:11

更新 5，GDB DISASS：

(gdb) disass
Dump of assembler code for function clGetPlatformIDs:
=> 0x0000000000402cc0 <+0>:     jmpq   *0x4b74e8(%rip)        # 0x8ba1ae
   0x0000000000402cc6 <+6>:     nop
   0x0000000000402cc7 <+7>:     nop
End of assembler dump.

更新 6，GDB 信息共享：

(gdb) INFO SHARED
From                To                  Syms Read   Shared Object Library
0x0000000077191000  0x00000000773384e0  Yes (*)     C:\Windows\system32\ntdll.dll
0x0000000077071000  0x000000007718eab4  Yes (*)     C:\Windows\system32\kernel32.dll
0x000007fefc081000  0x000007fefc0eb13c  Yes (*)     C:\Windows\system32\KernelBase.dll
0x000007fedf8d1000  0x000007fedf8e96aa  Yes (*)     C:\Windows\system32\OpenCL.dll
0x000007fefe101000  0x000007fefe1da628  Yes (*)     C:\Windows\system32\advapi32.dll
0x000007fefe061000  0x000007fefe0fe4bc  Yes (*)     C:\Windows\system32\msvcrt.dll
0x000007fefdcc1000  0x000007fefdcde39a  Yes (*)     C:\Windows\SYSTEM32\sechost.dll
0x000007fefc6a1000  0x000007fefc7cc914  Yes (*)     C:\Windows\system32\rpcrt4.dll
(*): Shared library is missing debugging information.

二进制文件、x64 和包含文件夹：

https://drive.google.com/file/d/0BxKA63T2GnKMRW02QWZnam5lSGM/edit?usp=sharing

更新7，GPUcaps情况：

GPUcaps 检测到 2 个 GPU：

• GPU 1：英特尔(R) 高清显卡 4000
• GPU 2：NVIDIA GeForce GT 630M

您可以在此处查看屏幕截图：

https://drive.google.com/file/d/0BxKA63T2GnKMa00tU1gydGNJeXc/edit?usp=sharing

更新8：

根据 @antiduh 的回答，我一直在尝试直接链接到 Windows\System32 文件夹中存在的 OpenCL.dll。我使用的是 mingw64。我明白了：

Invoking: Cross G++ Linker
g++ -L"C:\Windows\System32" -o "TestOpenCL"  ./HelloWorld.o ./HelloWorld2.o ./Test3.o   -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/OpenCL.dll when searching for -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/OpenCL.dll when searching for -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/msvcrt.dll when searching for -lmsvcrt
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/advapi32.dll when searching for -ladvapi32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/shell32.dll when searching for -lshell32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/user32.dll when searching for -luser32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/kernel32.dll when searching for -lkernel32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/msvcrt.dll when searching for -lmsvcrt

更新9： 我现在可以使用以下行手动编译、链接和运行示例代码。

g++ -I. s.cpp -L. -lOpenCL

我简化了一切，它就起作用了。这显然与 Eclipse 使用的编译和链接命令有很大不同。知道 eclipse 使用的哪个参数导致了问题吗？而且，为什么 Eclipse 首先编译为目标文件，然后尝试在两个单独的步骤中链接它们？

程序使用外部库共有三种方式：

• 静态链接：直接将库插入到可执行文件中。外部库以 .lib 文件形式呈现，只包含打包的 .obj 文件。您的程序照常调用库中的函数。编译器从库中提取可执行代码，插入它，并对其执行完整的链接。就好像您针对导入的函数进行编译一样，就像它们来自您自己的源代码一样。
• 加载时动态链接，也称为“隐式链接”：启动程序时加载库。外部库以包含可执行代码的 .dll 和包含 .dll 导出的 .lib 文件的形式呈现，由编译器和链接器暂时链接。链接器使用 .lib 来了解如何在运行时调用 .dll，并将延迟绑定放入程序中。当操作系统启动您的程序时，它会执行“加载时”链接 - 它会查找所有延迟绑定，尝试查找 .dll 文件，完成程序中延迟绑定的链接，并允许您运行文件。
• “纯”运行时动态链接，又名“显式链接”：直接调用 LoadLibrary。您的程序没有对任何 .lib、.dll 或其他文件的特定引用。您的程序开始运行，它本身使用 .dll 的字符串路径调用 LoadLibrary。 LoadLibrary 将 .dll 合并到您的虚拟内存中，然后您的程序调用 GetProcAddress 来获取指向您要调用的函数的函数指针。然后，您可以使用该函数指针进行调用。

如果没有 .lib，通常无法链接到 dll。编译器希望将这些函数调用引用解析为真实地址，但我们不想放入真实地址，因为我们希望将 DLL 加载到任意内存地址（DLL 是“可重定位的”）。

根据我的理解，用作导入库的 .lib 包含主程序直接链接的存根 - 因此程序中的所有调用都会通过存根。然后，存根引用“导入地址表”。当操作系统将 DLL 加载到进程的内存中时，它会通过填写 IAT 来完成此操作。然后，存根仅通过引用正确地址的间接跳转来调用 DLL。 IAT 中的插槽。

所以如果一个DLLMathLib有导出功能Factorial如果我的 exe 正在导入，那么导入的 .lib 文件有一个实际的函数 Factorial，我的 exe 会根据它进行静态编译。 .lib 中的阶乘类似于以下伪代码：

int Factorial( int value ) { 
   // Read MathLib's IAT which should always be at address 0x8ba100.
   // Factorial's real address gets stored in slot 2, so add 8 to the address
   // to read from.
   __asm jmp *0x8ba108; // nb this is an indirect jump.
}

然后我们希望当操作系统加载该 DLL 时，该 IAT 被正确填写，否则我们就会陷入虚无。

所以我认为发生的情况是，您正在针对一个 .lib 进行编译，但“加载时”链接到了错误的 opencl.dll。 IAT 从来没有被创建过，或者创建在错误的地方，所以你陷入了虚无；这就是为什么这一行创建了段错误：

0x0000000000402cc0 <+0>: jmpq *0x4b74e8(%rip) # 0x8ba1ae

那么让我们弄清楚为什么我们链接错误。您的计算机上可能有 3 组 opencl.dll/opencl.lib 文件：

• 来自 Kronos 的 opencl.lib/dll 实际上只是一个存根/加载器库，它可以找出计算机上真正的提供程序，并将函数调用分派到实际的正确库。
• opencl.lib/dll 来自 Intel，来自其 SDK 和驱动程序。
• opencl.lib/dll 来自 Nvidia 的驱动程序。

您实际上拥有以下哪些文件？我的估计是：

• 来自 kronos 的 opencl.dll 被安装到c:\windows\system32.
• Kronos 没有 opencl.lib
• 可能没有来自 nvidia 的 opencl.lib，因为您没有安装他们的 SDK。
• 您可能有来自 Intel 的 opencl.lib 和 opencl.dll，因为您确实安装了他们的 SDK。

您肯定链接到了 Intel opencl.lib，但似乎正在加载 Kronos opencl.dllc:\windows\system32。一种解决方案是在运行程序时将 Intel opencl.dll 放入程序目录中，让程序加载 Intel opencl.dll。

但是，您声明您能够使用此编译行使事情正常工作：

g++ -I. s.cpp -L. -lOpenCL

Windows 上的 gcc 有一些巧妙之处 -为了链接到一个库，你don't需要有.lib https://stackoverflow.com/a/3573527/344638。 Gcc 通过检查 dll 为您找出答案；当有人给他们一个 dll 但没有 lib 时，其他人已经想出了如何做同样的事情。在大多数其他编译器中，尤其是 Visual Studio，您需要有一个 .lib 和一个 .dll 来链接某些内容。这就是 Win SDK 安装数百个 .lib（例如 kernel32.lib）的原因。事实证明，如果编译器愿意的话，实际上可以推断它，但库作为一种古老的机制而存在。

不管怎样，你在 gcc 链接行上面运行了它，它使用搜索路径找到了一个合适的 opencl.dll，为它发明了自己的 .lib，并针对它进行编译；您启动了程序，它使用相同的搜索路径来获取 opencl.dll，它与您编译的路径相同，因此您的程序可以运行。呼。

我还是有一些建议：

• 查找来自 Kronos 的 opencl.lib 和 opencl.dll 对“可安装客户端驱动程序”ICD 加载程序 http://www.khronos.org/news/permalink/opencl-installable-client-driver-icd-loader。然后，该加载程序将弄清楚如何在运行时绑定到特定的提供程序（nvidia、intel 等）。
• 将 Kronos opencl.dll 与您的应用程序一起分发，这样您就不会意外地运行时链接错误的文件。
• 卸载 Intel SDK，假设它提供特定于 Intel 的 opencl.lib/opencl.dll 文件。

关于 libs 和 dll 的一些更相关的问题：

• 构建DLL文件时，生成的LIB文件是否包含DLL名称？ https://stackoverflow.com/questions/477461/when-building-a-dll-file-does-the-generated-lib-file-contain-the-dll-name
• 为什么 LIB 文件具有如此两面性的野兽？ https://stackoverflow.com/questions/6421693/why-are-lib-files-beasts-of-such-a-duplicitous-nature