Hello,

I'm using Windows MSVC2005/ver 8.

The terminology can be confusing, so I will try to define everything first.
Please anyone stop me if I'm wrong.

My goal is to not use any DLLs.

Libcurl.lib comes in two flavors: static and DLL. Let's call them '
libcurl-static.lib' and 'libcurl-dll.lib' The static version does not
require the separate libcurl-specific-DLL-library libcurl.dll. '
Libcurl-dll.lib' does. So two possible flavors so far.

On windows, with MSVC, there is a completely different set of static/dll
options which refer to whether your library requires certain Windows, not
libcurl, DLLs. These options are /MT, /MD, /MTd, and /MDd, which stand for
Multi-threaded static, Multi-threaded-DLL, and the debug ('d') versions of
each. So four options. Whether your library requires certain Windows dlls is
independent of whether your library requires libcurl.dll, so if we were to
take the original two options into account, there should be 8 (2x4)
possibilities.

I need to compile SSL support in, so I've retrieved the ssleay and libeay
libraries from OpenSSL. In the 0.9.8g binary version of OpenSSL---which I
think I got from here (
http://www.shininglightpro.com/products/Win32OpenSSL.html)---there are eight
versions of both ssleay and libeay, since these have their own
OpenSSH-related-dlls (which you can forego by using the static versions),
and support the four different Windows multithreading types, as discussed
above. So eight versions of ssleay/libeay too.

Currently I have a workflow set up that uses [OpenSSH-static]
libeay32MD.liband [OpenSSH-static]
ssleay32MD.lib. I want to have a workflow that uses [OpenSSH-static]
libeay32MT.lib and [OpenSSH-static] ssleay32MT.lib, but I can't because all
included lib files in MSVC must be of the same {'MT','MD','MTd','MDd'}
option, and while OpenSSH-static supports this, I have been unable to get
[libcurl-static] libcurl.lib to. By default, using the 'Win32->MSVC from
command line' instructions in libcurl's INSTALL file generates only
libraries with options of /MD, and not those of /MT, regardless of whether
it is static or -DLL with respect to libcurl.dll.

Using "nmake vc-ssl" will give you something that is /MD, and though it
would seem, according to an if-structure in "curl-*.*.*\lib\Makefile.vc8",
that using 'set RTLIBCFG=static' in your Visual Studio 2005 Command Prompt
would give you /MT, I've tried everything and haven't been able to get it to
work (under curl-7.17.1). It seems pretty clear the Make process supports
this, if only I could figure out what was going wrong.

Where the process starts to error is about here.

[...]
        link.exe /incremental:no /libpath:"../lib" /nologo /out:curl.exe/subsys
tem:console /machine:X86 libcurl.lib wsock32.lib bufferoverflowu.lib
wldap32.lib
 winmm.lib hugehelpr.obj writeoutr.obj urlglobr.obj getpassr.obj
homedirr.ob
j curlutilr.obj strtoofftr.obj mainr.obj curlr.res
LIBCMT.lib(setlocal.obj) : error LNK2005: __configthreadlocale already
defined i
n MSVCRT.lib(MSVCR80.dll)
LIBCMT.lib(setlocal.obj) : error LNK2005: _setlocale already defined in
MSVCRT.l
ib(MSVCR80.dll)
[...]

It looks like traditional MSVC /MT vs /MD library compilation problems. If
I had to guess some of the dependent libraries are still /MD. My OpenSSH
libraries? Maybe, but I've swapped them all in and out.

As I said previously, I'm using MSVC2005/ver 8. What I really want to have
is a version of libcurl.lib that is

1. Libcurl static, in that it doesn't rely on libcurl.dll
2. Windows static multithreaded, in that it is compatible with /MT
3. built to support SSL [OpenSSH-static, /MT versions of ssleay32.lib (
ssleay32MT.lib) and libeay32.lib (libeay32MT.lib)----as in no reliance on
dlls]
4. CURL_LDAP_DISABLED
5. not reliant on any other DLLs (for instance zlib, which I'm pretty sure I
don't need at all)
6. relatively up-to-date

If someone can tell me how to do this, I would be grateful. I someone
already has this lying around, or possesses the ability to create it, I
would be more than happy to pay a reasonable price. I have been unable to
find a copy online.

Thank you,
Kevin Lawler - kevin.lawler_at_gmail.com
Received on 2008-02-14