I have two C DLLs that I need to access in the same executable. I have header files and .LIB files for both libraries. Unfortunately a subset of the functions that I need to access have the exact same names. The best solution I have been able to come up with so far is to use LoadLibrary to load one of the DLLs and explicitly call its methods using GetProcAddress. Is there a way for me to implicitly load both libraries and somehow give the compiler a hint that in one case I want to call OpenApi in DLL A and in the other case I want to call OpenApi in DLL B?
I'm developing my executable in C++ using Visual Studio 2008 and the corresponding C runtime library (msvcr90.dll).
[Edit]
Commenter Ilya asks below what I don't like about the GetProcAddress solution. I don't like it for two reasons:
It used to be you could 'rename' an imported symbol using a linker .def file. You probably still can, but it's been so long since .def files have been widely used, it's difficult to locate documentation.
The current MSDN documentation lists the IMPORTS directive as a 'reserved keyword'. I'm not sure if this means they removed the functionality, or if they just don't want to support it anymore.
Here's on page that describes the IMPORTS directive:
http://www.digitalmars.com/ctg/ctgDefFiles.html#imports
Other kludgy alternatives are:
create wrapper functions for the conflicting APIs. Those functions can do the LoadLibrary()/GetProcAddress()
dance. All other non-conflicting functions can be implicitly linked as normal. Actually, this solution is probably the least kludgy of the 3 in this answer.
create 2 wrapper DLLs such that each links only to one or the other library with the conflicting names. Use differing names in the wrapper DLLs that simply thunk over to the real librarys. Note the wrapper libraries do not need to wrap all the API's - they just need to wrap the conflicting ones.
You may be able to build new import library files that rename the functions in question and then implicitly link with both DLL modules using these new import libraries. Here is a Microsoft Knowledge Base article that describes the process: How To Create 32-bit Import Libraries Without .OBJs or Source.
I managed to arrive at Mike B's kludgy alternative #2 (or #3 if you count the original suggestion) after I put a little bit more thought into the matter.
This is my favorite of the three for my specific case because it seems to require the least amount of work and could probably be the the most obvious to decipher to someone new looking at the code. I believe I can just follow these steps and be up and running:
If anyone's still reading this thread my followup question would be: "Is there anything wrong with this solution?"
Thank you to the responders for their help.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With