[Zlib-devel] zlib 1.2.7 released

r.kalbermatter at hccnet.nl r.kalbermatter at hccnet.nl
Thu Sep 6 02:38:52 EDT 2012


"Martin Schlemmer" <Martin.Schlemmer at nwu.ac.za> wrote:

> If you have VS or a SDK installed and setup before launching MSYS term,
you can use for x86:
>
>  lib -machine:X86 -name:zlib1.dll -def:zlib.def -out:zdll.lib
>
>and for x64:
>
>  lib -machine:X64 -name:zlib1.dll -def:zlib.def -out:zdll.lib
>
>Have a look at GTK+'s configure.in and gtk/Makefile.am to see how they
setup it.

Personally I don't think the problem is with creating a DLL in itself with
VS but the complications
when wanting to use that DLL. If you use anything newer than VS 6 to create
it, you end up with
a C runtime dependency that  either has to be linked statically into the DLL
or requires installation
of a redistributable C runtime that matches with the VS version used.  At
least for VS 2005 and
2008 and possibly others you also have the SxS problem if the C runtime is
not linked statically
into the DLL. SxS basically adds a manifest to the DLL that requires a
specific DLL version and not
just any version of that DLL. So installing "a" redistributable C runtime on
the target machine is
not enough as it has to be specifically the version that was used to create
the DLL in order to be
safe.
So why not using VS 6 then? Because it cannot create x64 DLLs. Also VS 6 is
already about 15 years
old and fully unsupported by now, including patches to installed C runtimes
on target machines.

Also as one goes and uses newer VS versions, their C runtime also depends on
newer Windows
API features which makes the resulting DLL not load on older OS versions.

The respective SDK compilers have the same troubles. The story gets
supposedly different if you
use a WDK based toolchain. This toolchain links the DLL to the generic
MSVCRT.DLL and adds an
extra static library to the DLL that targets OS differences concerning
exception handling support
and such. As earlier OS support the programmer chooses as bigger this added
static library gets.

So the question is, what should the created DLL support as earliest OS
version? Is the requirement
to install a specific  C runtime redistributable acceptable?

The most flexible solution would be probably to use a MinGW based toolchain,
but I haven't yet 
gotten the time and courage to install one which allows me troubleless
compilation for x86 and x64
at the same time.

Rolf Kalbermatter





More information about the Zlib-devel mailing list