Date: 2001-11-09 10:21:00
--- In boost_at_y..., "Steve Anichini" <sanichin_at_2...> wrote:
> I can't think of any reason a library should require linking to the
> runtime instead of the LIB C runtime.
Then you aren't thinking hard enough ;). Boost.Threads *must* be a
DLL in order to manage thread TLS cleanup (and this means dynamic
linking to the RTL). There are several other reasons that could
require this as well.
> For some applications, linking to the static version of the runtime
> more sense. For example, with static linking one doesn't have to
> redistribute the C runtime (msvcrt.dll) with your app. Even though
> version of msvcrt.dll ships with all Win9x and WinNT systems, it's
> necessarily the version you need if you need one with a bug fix
from one of
> the VC6 service packs. Also, if you are using MFC and linking to
> you have to distribute the MFC DLL as well for the same reason.
The need for distributing the C RTL DLL is diminishing to the point
of nearly not being an issue. The msvcrt.dll exists on all MS
supported platforms. If there's a bug in an older version the
response simply is "install the latest SP" because of this.
MFC is a different matter, but Boost doesn't directly use MFC and I
think it at least a little unreasonable to expect MFC to affect the
technical decisions made for Boost libraries. In any event, there
are simply times that you have no choice on this subject.
> Yes, static linking produced larger executables. But it also is an
> to know exactly what version of the C-runtime and MFC you are using.
> Otherwise you can find yourself in DLL hell, and supported
> cope with multiple DLL versions didn't really exist until Windows
> Windows XP introduces a better mechanism, but not everyone lives in
> where they can ignore NT 4, or Pre-98 Second Edition Win9x.
Pre-98 will no longer be supported by MS after next month, so it
shouldn't be an issue for you either. I believe NT 4 supports the
concepts you're discussing starting with SP 5, though someone will
correct me if I'm wrong. However, even NT 4 is on the radar scope
for being dropped from support by MS within the first half of next
year (the same is true of 98).
> If you still don't believe me, try writing a production-quality
> that deals with DLL/COM redirection and you will realize the pain
> can cause! It's a very difficult thing to get right.
We install several applications today using several (over 30) DLLs
and experience no DLL hell. All application DLLs get installed in
the same directory as the application's executable eliminating any
chance for DLL hell from anything other than the MFC and C RTL DLLs.
However, these DLLs have been stable for so many years that it's not
really an issue either, even ignoring that most (all?) supported OSes
allow you to drop these DLLs in your application directory as well if
you truly find it an issue.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk