Theoretically at least, I don't see why this would cause a problem. You intentionally leak, but the leak is benign since it occurs only right before the application exits. But most users won't code this way, nor do I want to have to deal with the support requests/questions this would cause. So, unless you have some suggestion as to how I can enable this usage with out causing confusion, I'm not sure I'd care to re-enable static builds. But you could probably fairly easily hack things to build that way yourself.
No, I wasn't going to ask you to re-enable static linking because of this. As you rightly pointed out in the other thread, you have to make the library safe for all possible cases which is what you are doing.
If we did decide to go this route, then we would certainly handle building the lib ourselves.
Our problem with DLLs is this: We work on many projects. Some are in maintenance only mode, so don't get many updates. The next project may use boost-1.30.0 and then go into maintenance. I may then be working on a project which uses boost-1.32.0 and would like to keep both dlls available on the system.
Current idea for doing this is re-naming the boost dlls to boost_thread-1.30.0.dll etc so that I can have 1 bin directory with all the dlls in, and each project would link and use the correct dll. I wonder if support for this could be built into the builds?
Cheers
Russell
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
