Re: [Boost-users] [filesystem] std::bad_alloc during dll initialization when migrating to filesystem v3

Subject: Re: [Boost-users] [filesystem] std::bad_alloc during dll initialization when migrating to filesystem v3
From: Nat Linden (nat_at_[hidden])
Date: 2011-04-18 14:00:19

On Mon, Apr 18, 2011 at 10:53 AM, Richard Ulrich <richi_at_[hidden]> 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.