Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
curl-7.53.0\lib\urldata.h(411) : error C2061: syntax error : identifier 'CtxtHandle' #1276
Compiling on Windows 10 with Visual Studio 2010 SP1 generates errors, when using OpenSSL 1.1.0e with SSPI enabled. Normally, I don't actually specify ENABLE_SSPI in the command line, but it is enabled by default. I've been using this same command line for a number of releases of curl. So, I'm not doing anything new.
If I use WinSSL and enable SSPI, it compiles fine.
I'm guessing that SSPI is now somehow tied to WinSSL.
Edit: Added OpenSSL version
I did this
nmake /f MakeFile.vc mode=static RTLIBCFG=static VC=10 WITH_SSL=static WITH_ZLIB=static GEN_PDB=yes MACHINE=x86 MAKE="NMAKE /e" SSL_LIBS="libssl.lib libcrypto.lib crypt32.lib user32.lib"
I saw the following output
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
configuration name: libcurl-vc10-x86-release-static-ssl-static-zlib-static-ipv6-sspi
Windows 10 compiling with Visual Studio 2010 SP1
referenced this issue
Feb 22, 2017
Testing a similar patch, results in a few minutes:
diff --git a/lib/urldata.h b/lib/urldata.h index 648b3e81d..7f87913a9 100644 --- a/lib/urldata.h +++ b/lib/urldata.h @@ -136,8 +136,10 @@ #undef realloc #endif /* USE_AXTLS */ -#ifdef USE_SCHANNEL +#if defined(USE_SCHANNEL) || defined(USE_WINDOWS_SSPI) #include "curl_sspi.h" +#endif +#ifdef USE_SCHANNEL #include <schnlsp.h> #include <schannel.h> #endif
Thanks guys. I had tested f77dabe using Windows SSL and SSPI in Windows 7. I think we should have a CI test combination for SSPI and another SSL backend like OpenSSL. Using that combo I see it also:
I landed Viktor's fix in f4739f6. I expect other people will run into this issue in the just released source so maybe we should leave this issue open for a bit.
winbuild makefile defaults to SSPI enabled regardless of SSL backend. I know a fair amount of people use winbuild for Windows builds but I don't know what SSL backends they're using. I'd imagine based on the poll results that show an overwhelming popularity for libcurl w/OpenSSL that it will be an issue that affects a number of people. How about delay the feature window for a few days and see how many reports or +1s or whatever come in for this?
Met this issue as well, f4739f6 fixes it. No issues sighted, other than that. IMHO could make sense to have an official fix release, as 7.53.0 contains a security fix. Otherwise, just applying the aforementioned revision is sure something one can live with.
Note that I've sent a notification to the OpenSSL guys about lhash.h. They use some macro's to construct things, but there is something wrong there (and quite difficult to fix), see: openssl/openssl#2214. The lhash.h issue is indendent from cURL AFAIK, but related to openSSL 1.1.0 (any version).
I ran into the same issues when I tried out cURL 7.53.0 (with openSSL 1.1.0e and previously 1.1.0d with cURL 7.52.1)