[FFmpeg-trac] #6893(avutil:new): Compile hwcontext_opencl.c: undefined reference to several OpenCL functions

[FFmpeg]

#6893: Compile hwcontext_opencl.c: undefined reference to several OpenCL functions
------------------------------------+----------------------------------
             Reporter:  LigH        |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avutil
              Version:  git-master  |               Resolution:
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+----------------------------------

Comment (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".

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6893#comment:11>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker