Question

…, a follow up to this.

From the answers I’ve been given to my referenced question I’ve learned that:

• different compilers use different name decoration, which makes it impossible to use a C++ dynamic library built with compiler A in a project built with compiler B,
• the library can be built as static saving me including n header and source files in the project or exporting symbols. (It still won’t save rebuilding the library for use with a different compiler.)

Having a closer look at SDL in the light of what’s been said, I’ve realized, that its linking has two layers: in my SDL project, I link statically against libSDL.a, which will, in turn, link dynamically against SDL.dll, thereby elminating the need for different .dll versions for different compilers.

The question is whether this is really the case and a viable solution to the problem, or am I missing something (and what)?

Answer 1

I think your approach is right. I’d put it this way:

• For a dll to be usable by different compilers, it must contain only C functions (they can be compiled using a C++ compiler using extern C)
• As usual with dlls, a static import library can be used so that functions in the dll can be called directly, rather than needing to be loaded by name
• Instead of a regular import library, you could have a wrapper library that wraps the dll’s C functions in C++ classes and functions