cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: building for Windows with SSL -- patch for config-win32.h

From: David Byron <DByron_at_everdreamcorp.com>
Date: Thu, 4 Dec 2003 12:18:31 -0800

On Thu, 4-dec-2003, Gisle Vanem wrote:

> "David Byron" said:
>
> > /* Define this to 'int' if socklen_t is not an available typedefed
> > type */ -#if !defined(ENABLE_IPV6) && !defined(USE_SSLEAY)
> > +#if !defined(ENABLE_IPV6)
> > #define socklen_t int
> > #endif
>
> 'socklen_t' should be in MSVC's <ws2tcpip.h> unless your SDK
> isn't too old. Mine is from 15-Oct 2002.

I'm not sure how old my SDK is, but I searched for ws2tcpip.h and found it
in my VC6 installation (in VC98/include). That file doesn't contain
anything about socklen_t. It's also in my Visual Studio .NET installation
in Vc7/PlatformSDK/Include, and that file contains:

typedef int socklen_t;

Not meaning to be argumentative, but this doesn't seem so relevant to the
patch I sent. Seems to me whether or not we need the #define is independent
of whether we're using SSL. The makefiles are still for VC6, yes? I'd love
if someone would contribute makefiles, solution files, etc. for Visual
Studio .NET, but until then, don't we need socklen_t in config-win32.h?
Apologies if I sound like a punk. I don't mean to.

> > I also had to manually generate lib/ca-bundle.h. This is
> what I used.
> >
> > #define CURL_CA_BUNDLE "curl-ca-bundle.crt"
>
> I haven't used MSVC in some time, but
> #define CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")
>
> is probably better so the full path of the file can be known
> w/o rebuildng.

Thanks. I'll try this. Is this something we "should" check in as
ca-bundle.h.cvs since we don't have autoconf/automake, etc. to generate it
for us?

-DB

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Received on 2003-12-04