Opened 12 days ago

Closed 4 days ago

Last modified 4 days ago

#6893 closed defect (invalid)

Compile hwcontext_opencl.c: undefined reference to several OpenCL functions

Reported by: LigH Owned by:
Priority: normal Component: avutil
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Attachments (2)

logs.zip (161.6 KB) - added by LigH 12 days ago.
Archive of compilation log files collected by media-autobuild_suite
OpenCL.def (2.0 KB) - added by LigH 4 days ago.

Download all attachments as: .zip

Change History (16)

Changed 12 days ago by LigH

Archive of compilation log files collected by media-autobuild_suite

comment:1 Changed 11 days ago by 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?

comment:2 Changed 11 days ago by heleppkes

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.

comment:3 Changed 11 days ago by 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.

comment:4 Changed 11 days ago by 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?

comment:5 Changed 11 days ago by 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).

comment:6 Changed 11 days ago by 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).

comment:7 Changed 11 days ago by heleppkes

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

comment:8 Changed 11 days ago by 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?

comment:9 Changed 11 days ago by 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.

comment:10 Changed 11 days ago by heleppkes

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.

comment:11 Changed 10 days ago by 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".

comment:12 Changed 4 days ago by Gyan

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

comment:13 Changed 4 days ago by cehoyos

  • Resolution set to invalid
  • Status changed from new to closed

comment:14 Changed 4 days ago by 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?

Changed 4 days ago by LigH

Note: See TracTickets for help on using tickets.