The problem is about inability of Windows to "merge" static data from different DLLs into one place.
What if I were to move the implementation details that require being only defined once to source files, and by default have those source files included by the headers. Then if some macro is specified, I could omit these inclusions and instead link to a separate dll that is a build of these files. Would this solve the problem?
Hi Jason and everybody. There is a scenario which I think is not solved by this approach, but on the other hand may be not solvable a all (I'm pessimistic today...) Consider a singleton inside a *static* Windows library, which is linked into a dynamic library, *and* into an executable, which also links with the DLL. Something like this: lib (contains a singleton) | \ | \ | dll | / | / exe Now the singleton appears twice, once in the DLL's memory, and once in the exe's memory. This is something I found when writing my own singleton library (like most of us ;-) ). At first I noticed that singletons in a DLL are created twice, so I created a .cpp file and used dllexport/dllimport (just like the solution mentioned in this thread) to insure one instantiation. This worked for the simple DLL case, but not the more complex case I described above. I haven't been able to find any workaround (except for being really careful not to create such situations), and I really hope you can... Actually, I didn't have any time to look at your library (very unfortunate), but it looks like it will probably suffer from the same problem as my own library. I hope I'm wrong... but it worth a check. Hopefully Boost will soon have a singleton library, Yuval