Cross platform dynamic linking (Windows to linux)

Question

I have an application which I have managed to keep reasonably cross-platform between windows and Linux. Cmake and Boost have been helpful in this endeavor.

The time has come to link to a .dll which has been written for windows. If I can put off the conversion of the dynamically linked library it would be a good thing. Other windows applications connect up to this library like this:

HINSTANCE dll;
dll = LoadLibraryA(filename);
//...
libFuncPtr = (libFuncPtr)GetProcAddress(dll, "libFunc");

I'd like to know if there are generic analogs to these functions or is it time to start dropping in my system specific preprocessor directives? The Current Priority for Developemt is Windows, It's understood there will have to be a Linux port of the library for the Linux build to work, but I'd like to keep the calling code as generic as possible.

Answer 1

A good example of such a class is Qt's QLibrary, which has a uniform interface for loading dynamic libraries into programs.

see http://qt-project.org/doc/qt-4.8/qlibrary.html for more details.

Since Qt is cross platform, it can be used everywhere. Since Qt is open source, you can have a peek at the code. I would not use it directly if you don't need other stuff from Qt, as it comes with a big linkage baggage by itself.

I remember implementing something along these lines in the past, but the code is long gone.

Answer 2

You can use Poco Shared Library.

Answer 3

Another options is dlfcn-win32. https://code.google.com/p/dlfcn-win32/ It use dlopen(), dlsym() and dlclose() just like in Linux

Answer 4

If you have access to the DLL's codebase (which it sounds like you do), then one option would be to use implicit linking on Windows to eliminate the calls to LoadLibrary and GetProcAddress.

When you get around to porting the library to Linux, you can build it as a static library and link your application against it so that no changes are required to your codebase.

Answer 5

Start dropping system specific preprocessor directives.

You could write an intermediary interface to provide functions like LoadLib(), LoadSym(), etc, that calls the aproppriate native API. In other words, when compiling for Windows LoadLib() will use LoadLibraryA() and on Linux it will use dlopen().

This will let you hide this ugly part of the code from your main code so it stays more readable.