From: John Maddock (john_at_[hidden])
Date: 2004-01-11 10:41:57
> Still does not work because:
> The threading dll that has been compiled with bjam is obviously
> built with a linkage to use the static C runtime library.
> ... which is bad, since it forces me to use the static version of MFC as
No the current cvs version requires the dynamic dll (and this is what a bjam
build will give you)
> I figured this out by not using the auto_link.hpp. When using the
> things get even worse, since auto_link thinks that
> "Mixing a dll boost library with a static runtime is a really bad idea..."
It is, especially in this case: the thread lib can throw exceptions, so the
code that catches a Boost.Thread generated runtime_error had better be using
the same dynamic runtime as boost.threads or... crash.
> One resolution would be to use a threading DLL that does not depend
> on the C-runtime (which is feasible, altough not straight forward - one
> to carefully factor out the absolutely necessary DLL code and use
> instead of DllMain entry point)
> or to force users to use DLL version of MFC too.
> An other possible solution would be to reconsider my version that can
> do without an explicit DLL. (Michael Glassford, are you listening?
> the thread monitor still necessary.)
> It might well be that it is also possible to choose boost DLL with
> user selectable C runtime library. But I do not know how. Is there a way
> do so?
No the dll and your code must share the same runtime, unless as you say you
can factor out the part that absolutely has to be in a dll and build this
without C runtime support (probably as a strict C dll, that just forwards
dllmain notifications to a callback function).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk