Reputation: 1516
I am currently looking at an issue where a project is generating a DLL. Now it is built upon a chain of other projects which are all C++, so they're just .lib files being linked in.
In this case one project uses OpenCL, however I don't believe those code paths are being run. However it would appear that just having OpenCL linked in causes the output .DLL to have a dependency on OpenCL.dll.
Please correct me if I am wrong here (in which case I'll go over the code with a fine-toothed comb to ensure no OpenCL calls are being executed).
I am not sure how Visual Studio (or dependency walker?) figures out which DLL's are dependencies for a given DLL. However I don't want the OpenCL.dll dependency.
What are my options?
One possible one is to take the project with the OpenCL code and refactor so some portion of it can be build with the OpenCL portion excluded from the build. However this will be a fair chunk of work so I am really hoping for something simpler.
Upvotes: 0
Views: 130
Reputation: 294197
If you link a lib
you depend on the dll
. The easiest thing for you would be to add /DELAYLOAD
for this dll
:
The /DELAYLOAD option causes the DLL that's specified by dllname to be loaded only on the first call by the program to a function in that DLL.
This generates a 'soft' dependency which only kicks in if you call a function that actually needs the DLL. Make sure you read Constraints of Delay Loading DLLs.
The other option (which I don't recommend) is to use runtime binding via LoadModule
and GetProcAddress
, then invoke functions via the pointer to function. This removes any dependency, but you are tasked to implement all check, all errors if the DLL is missing, and it can easy go astray if you mismatch the function signature/call convention. Ultimately, you'd be implementing /DELOAYLOAD
manually.
Upvotes: 1