On Mon, Apr 18, 2011 at 10:53 AM, Richard Ulrich wrote:

If I link the filesystem lib as dll, then it works. Should I file a bug, or is there a trick to suppress multiple initialization?

We have used static versions of the boost libs in different dll's for years, and never ran into similar problems.

This isn't a boost thing -- it's a DLL thing. Any static library bound into multiple DLLs in the same process could cause you problems. More specifically, every static variable in that static library will have a distinct instance per DLL. Generally, coders use static variables to share state among all callers. That is, we assume a single instance of any particular static variable. You can see that it becomes problematic when that assumption is violated -- though the nature of the symptoms strongly depends on the use of that variable, the specific pattern of calls between DLLs, etc. If the library of interest happens to have no static variables -- or if, in your usage, you don't happen to cause it to modify any of its static variables -- you can get away with multiple instances in the process. That's a tough thing to guarantee for a third-party library, though, and -- as you've seen -- it can change from release to release. My rule of thumb is to prefer dynamic libraries, with two exceptions: 1. If I'm building my entire application as a single executable, it's okay to link it with static libraries. 2. If I can guarantee that, in my executable and all its dynamic libraries, only *one* of them uses a particular library, it's okay to link that library statically into the dynamic library in question. (But that too is subject to change over time, particularly with the kinds of general-purpose libraries provided by Boost.) This isn't a Boost bug.