Compile hwcontext_opencl.c: undefined reference to several OpenCL functions

[LigH]

Trying to compile ffmpeg for Win32 with OpenCL support in media-autobuild_suite.

Likely error:
LD      libavutil/avutil-56.dll
libavutil/hwcontext_opencl.o:hwcontext_opencl.c:(.text+0xe33): undefined reference to `clCreateImage@28'
libavutil/hwcontext_opencl.o:hwcontext_opencl.c:(.text+0x137f): undefined reference to `clGetExtensionFunctionAddressForPlatform@8'
libavutil/hwcontext_opencl.o:hwcontext_opencl.c:(.text+0x153b): undefined reference to `clGetExtensionFunctionAddressForPlatform@8'
libavutil/hwcontext_opencl.o:hwcontext_opencl.c:(.text+0x3431): undefined reference to `clGetExtensionFunctionAddressForPlatform@8'
libavutil/hwcontext_opencl.o:hwcontext_opencl.c:(.text+0x3472): undefined reference to `clGetExtensionFunctionAddressForPlatform@8'
libavutil/hwcontext_opencl.o:hwcontext_opencl.c:(.text+0x34b3): undefined reference to `clGetExtensionFunctionAddressForPlatform@8'
libavutil/hwcontext_opencl.o:hwcontext_opencl.c:(.text+0x35be): more undefined references to `clGetExtensionFunctionAddressForPlatform@8' follow
collect2.exe: error: ld returned 1 exit status
make: *** [/build/ffmpeg-git/ffbuild/library.mak:103: libavutil/avutil-56.dll] Error 1

Log file collection attached.

[LigH]

Archive of compilation log files collected by media-autobuild_suite

[LigH]

Does OpenCL support possibly require a specific minimum API version which e.g. a GeForce 9600 does not provide, but a GT 450 does?

[Hendrik]

clCreateImage and clGetExtensionFunctionAddressForPlatform are both OpenCL 1.2
Both of those have OpenCL 1.1 variants (clCreateImage2D and clGetExtensionFunctionAddress), but if its possible to make it compatible or if just a configure check is required is up to Mark.

[jkqxz]

From your build log the test for CL_VERSION_1_2 passes, so your implementation must have those functions. I would guess that you are probably linking to the wrong library - maybe a vendor library rather than the ICD loader? I don't think this is an ffmpeg problem.

[LigH]

Indeed, it used to build for several months without problems, being a rather automatic build suite, fortunately; I would not know how to do all that manually.

Now, what may be my next steps? Checking something specific? Deleting something to force it being rebuilt?

[jkqxz]

Either:

• Find the library which matches the headers you are using and link to that.
• Build without --enable-opencl (if you don't have a device which can use it).

[LigH]

I am no developer, my experience in C and Unix is limited. The media-autobuild_suite has to work automatically if it is working correctly, I don't intend to patch something when it's not clearly necessary; I would rather delete the whole ffmpeg working directory and let it clone anew.

Passing the CL_VERSION_1_2 check appears to be somewhat wrong, may it either be that my GPU does not support it at all, or that the drivers got somewhat downgraded since the last run of the build suite. I wonder if I should blame Microsoft drivers from the Windows Update, and re-install drivers from Nvidia.

At the moment, GPU-Z detects OpenCL 1.1 CUDA 6.5.51 for this GeForce 9600 GT with Nvidia drivers 342.01 (latest for Series 9).

[Hendrik]

We cannot debug some external build system for you, so maybe you should take this to them.

[LigH]

What I wonder about even more: Does compiling ffmpeg with OpenCL support already require an OpenCL capable machine? If yes: Will the built binary then possibly rely on its specific capabilities?

[jkqxz]

Compiling ffmpeg with OpenCL requires headers and a linkable library of version at least 1.2. The library can be either a vendor ICD, which will give you specific support for some set of platforms from that vendor, or the standard ICD loader, in which case it should be portable. It is recommended but not required that you link to the ICD loader.

[Hendrik]

For the record, I just checked, and the OpenCL.dll in my Windows install with an NVIDIA driver is the "Khronos OpenCL ICD" 2.0.4.0 (with OpenCL 1.2 hardware support). Of course this is a more recent GPU then your 9600, but the point is its not an NVIDIA specific library.

[LigH]

I let the suite clone ffmpeg git anew by deleting the whole subdirectory branch. A file msys64/mingw32/include/CL/cl.h does exist, it defines symbols for at least version 1.2; but there is no other "cl.h" file in the newly built ffmpeg source branch after the compilation breaks again.

A few weeks ago, building ffmpeg with --enable-opencl worked still (e.g. ffmpeg version N-89073-gff8f40a630), so simply compiling ffmpeg worked before, but just recently linking libavutil/avutil-56.dll broke. Still, it confuses me that it

a) already breaks the compilation, not only the execution of the finished binary

b) breaks the compilation so late, apparently while linking, not with a compiler warning about missing headers or a failed version check

c) passes the compilation on another PC with hardware supporting OpenCL 1.2

You wrote that I should "Find the library which matches the headers you are using and link to that", and "It is recommended but not required that you link to the ICD loader". As I don't do that actively, just let the suite run, how do I discover what it does, where shall I look for which patterns? I would assume that because the purpose of the suite is to build quite portable executables on any machine, it will prefer the compatible way of loading libraries over using a hardware specific library...

Does the linking process actually access C:\Windows\System32\OpenCL.dll? I noticed that this file is rather old (May 2012), while an OpenCL64.dll below C:\Windows\System32\DriverStore\FileRepository is much more recent (Nov. 2016), yet reporting as "Khronos OpenCL ICD" with version 1.0.0.0. But both the nvopencl[64].dll at the same locations are identical, reporting as "NVIDIA CUDA 6.5.51 OpenCL 1.1 Driver, Version 342.01".

[Gyan]

I resolved this by deleting libOpenCL.a in local64/lib. This gets the script to generate a new static lib.

[LigH]

Following this suggestion, I got a new library installed, but the issue persists for me.

This libOpenCL.a contains symbols clCreateImage3D(@44) and clCreateImage2D(@36), but not clCreateImage(@28) alone (one of the symbols reported as missing while trying to link avutil-56.dll).

The OpenCL.def used does not contain this export either. Snippet from the header (whole file will be attached):

;
; Definition file of OpenCL.dll
; Automatic generated by gendef
; written by Kai Tietz 2008
;

Is this content specific to my hardware? If so, maybe that's the reason why my build is not as hardware independent as expected?