You have to do that anyway -- the C++ ABI (e.g. name mangling) isn't portable across compilers, so a library built by one compiler very likely just wont work with another compiler, no matter how simple/complex the interface is.
For a well defined API, this should never cause a problem. Now if you're going to start passing references to std::string / std::vector<> across your DLL boundary, then you're going to have issues. For a dll that defines a single C entry point (e.g. CreateMySDK()), then uses nothing but virtual interfaces (or infact, any C++ class that restricts communication to functions only, again making sure that the data types you pass into args are of a known size), then you should have no problem.
Every compiler includes some form of libtool to generate a link library for a DLL compiled with another compiler. It's not an impossible task....
That. Even with a library built exactly for the compiler I'm currently using, some optimization flag set to a different value is already enough to render the library unlinkable. Give me the source and don't make a fuss about it.Which means you have been ignoring warning C4251 (i.e. you have a function arg, return type, or member var, in your DSO interface that is being statically linked in from another library. This is bad news!) . If you fix all of those warnings, the problems you describe will never happen.