2007/3/15, Jonathan Arnold wrote:

> Yes, there is no doubt that mixing and matching MS C runtimes is a recipe for
> disaster. But that doesn't really have anything to do with *using* a DLL, as
> long as its C runtime is the same. In fact, it has to be the same. So if my
> program uses static libs, I must have a DLL that uses static libs. Again, just
> because I want to use curl as a DLL doesn't mean that my entire app needs to
> be dynamic (we ran into a similar problem on Mac OSX, trying to not require
> dynamic libraries to be delivered).

If you build a DLL named first.dll with the static MS C runtime, the
static MS C runtime library gets linked _into_ the DLL This might even
be the desired thing if you don't want or cannot provide the dynamic
MS C runtime libraries.

If you build another DLL named second.dll with the static MS C
runtime, the static MS C runtime library also gets linked _into_ the
second DLL.

Now you build a program that uses the above first.dll and second.dll.
Now you have a nice program which is granted to be using at least TWO
_different_ copies of the static MS C runtime each of it with separate
copies of all C Run-time functions and global variables.

Among other things this means that if a buffer is allocated in
first.dll the program will misbehave if you try to free the buffer in
second.dll.

This is reason enough to mostly _NEVER_ build a DLL linked with the
static MS C runtime.

If we are speaking of a DLL, let's call it third.dll, of wide and
uncontrolled distribution which might be used no one knows how and
which might be used in a program which is using other DLLs the only
safe way of building third.dll so that it does not misbehave is
linking it at creation time with the MS dynamic C runtime, and not
with the static one.

On the other hand, if you have full control of which libraries are
used with your program you might chose to violate some rules, after
all its your responsibility. But watch out, with DLLs having full
control means that you build all of them, and that you build them with
names that don't match DLL names that could be found in the wild,
otherwise you are in big trouble.

libcurl is not an inshop library, it is more like third.dll mentioned above.

For the license it has you can create an inshop library with your very
own particular settings and C runtime linkage , but in that case most
probably you should also be using a file name different from the
libcurl standard one.

> That's why, for ease of use, there needs to be 8 targets. The OpenSSL folks deliver
> 8 libraries too, so you can create all the versions of the DLL you might want
> to use

They can do whatever they want. If something is wrong, it is wrong no
matter who, when or where it is done. A Dll built with a static MS C
runtime is just something that should be avoided by _ALL_ means in a
library of wide use, uncontrolled distribution and free support.

http://support.microsoft.com/default.aspx?scid=kb;en-us;94248

-- 
-=[Yang]=-