Static build of loader broken due to addition of DllMain

[BtbN]

Commit c987c97 added a DllMain function, which is unconditionally added, even when OPENCL_ICD_LOADER_BUILD_SHARED_LIBS is off.
This leads to DllMain being part of the resulting static library, which then causes a linker error when trying to link it into another shared library, like FFmpeg in this case.

Defining a DllMain function should only happen when actually building a shared library.

[bashbaug]

Hi, can you check if #270 fixes this issue? Thanks!

[BtbN]

Yes, that change looks like it fixes the issue.
I've removed my workaround for the issue and will tell you shortly if it passes CI.

Looking at the discussion in #270, what would be the correct way to optionally depend on OpenCL at runtime?
If I link against the loader as a shared lib, and the user has no OpenCL loader on their system, the binary will fail to run even if the user would have never touched OpenCL.
Yet statically linking the loader seems to be discouraged.

It's a bit paradoxical. There is a loader that abstracts OpenCL in a driver-agnostic way.
But seemingly one needs a loader for that loader to be actually able to use it conditionally?
Vulkan has the same issue. I actually ended up writing a loader for the Vulkan loader just so I can make it an optional runtime dependency.

[BtbN]

Yes, the build passes now without workaround.

[jenatali]

what would be the correct way to optionally depend on OpenCL at runtime?

My suggestion would be delay-load linking. The library isn't loaded until you try to call into it, at which point the calls can fail. You can provide a library that implements the delay-load stubs that return error codes.

Note that Windows has included an OpenCL loader out of the box for ~6 or 7 years now, regardless of whether you have a driver with OpenCL support. A Vulkan loader has been present for ~3 or 4.