Attached is a patch that fixes two similar problems building current CVS
on Cygwin, SSPI and LDAP. These are both cases where the code wants to
call something from the Win32 API, but Cygwin targets a POSIX
environment and WIN32 is not defined. This means that the standard
Windows headers are not included (for good reason, e.g. winsock2.h tries
to redefine everything) which leads to errors when it tries to include
sspi.h or winldap.h. This patch simply makes two exceptions for Cygwin
to go ahead and include windows.h. This seemed like the least invasive
way of accomplishing this.

Running the testsuite, there are a number of errors:

TESTFAIL: These test cases failed: 67 68 69 81 89 90 91 100 101 150 155
159 162 169 170 176 209 213 215 239 243 250 251 265 267 280 504 521

I took a look at the logs and the majority of these fall into two
categories:

A. NTLM differences - perhaps due to --enable-sspi (which a user
requested that I enable for the next iteration of libcurl Cygwin
packages) that the testsuite is expecting the wrong thing. There are a
number of these:

test 067...[HTTP with NTLM authorization]
../src/curl --output log/curl67.out --include -v --trace-time
http://127.0.0.1:8990/67 -u testuser:testpass --ntlm >>log/stdout67
2>>log/stderr67

 protocol FAILED:
--- log/check-expected 2007-04-08 18:58:31.828125000 -0700
+++ log/check-generated 2007-04-08 18:58:31.828125000 -0700
@@ -1,10 +1,10 @@
 GET /67 HTTP/1.1
-Authorization: NTLM TlRMTVNTUAABAAAABoIIAAAAAAAAAAAAAAAAAAAAAAA=
+Authorization: NTLM
TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==
 Host: 127.0.0.1:8990
 Accept: */*
 
 GET /67 HTTP/1.1
-Authorization: NTLM
TlRMTVNTUAADAAAAGAAYAEAAAAAYABgAWAAAAAAAAABwAAAACAAIAHAAAAA
+Authorization: NTLM
TlRMTVNTUAADAAAAGAAYAFUAAAAYABgAbQAAAAAAAABIAAAACAAIAEgAAAAFAAUAUAAAAAAAAACFAAAANoKAAgUBKAoAAAAPVEVTVFVTRVJCT09DSFpkQwKRCZFMhjj0tw47wEjKHRH
 Host: 127.0.0.1:8990
 Accept: */*
 
Are these real errors or is it that the testsuite does not accomodate
SSPI?

B. CRLF problems with expected output. All the ftp tests that get a
directory listing fail like this:

test 215...[Get two FTP dir listings from the same remote dir: no second
CWD]
../src/curl --output log/curl215.out --include -v --trace-time
ftp://127.0.0.1:8992/a/path/215/ ftp://127.0.0.1:8992/a/path/215/
>>log/stdout215 2>>log/stderr2
OUT: 220- _ _ ____ _
OUT: 220- ___| | | | _ \| |
OUT: 220- / __| | | | |_) | |
OUT: 220- | (__| |_| | _ <| |___
OUT: 220 \___|\___/|_| \_\_____|
IN: USER anonymous
IN: PASS ftp_at_example.com
IN: PWD
IN: CWD a
IN: CWD path
IN: CWD 215
IN: EPSV
IN: TYPE A
IN: LIST
IN: EPSV
IN: LIST
IN: QUIT

 data FAILED:
--- log/check-expected 2007-04-08 18:58:49.562500000 -0700
+++ log/check-generated 2007-04-08 18:58:49.562500000 -0700
@@ -1,11 +1,11 @@
-total 20
-drwxr-xr-x 8 98 98 512 Oct 22 13:06 .
-drwxr-xr-x 8 98 98 512 Oct 22 13:06 ..
-drwxr-xr-x 2 98 98 512 May 2 1996 .NeXT
--r--r--r-- 1 0 1 35 Jul 16 1996 README
-lrwxrwxrwx 1 0 1 7 Dec 9 1999 bin -> usr/bin
-dr-xr-xr-x 2 0 1 512 Oct 1 1997 dev
-drwxrwxrwx 2 98 98 512 May 29 16:04 download.html
-dr-xr-xr-x 2 0 1 512 Nov 30 1995 etc
-drwxrwxrwx 2 98 1 512 Oct 30 14:33 pub
-dr-xr-xr-x 5 0 1 512 Oct 1 1997 usr
+total 20
+drwxr-xr-x 8 98 98 512 Oct 22 13:06 .
+drwxr-xr-x 8 98 98 512 Oct 22 13:06 ..
+drwxr-xr-x 2 98 98 512 May 2 1996 .NeXT
+-r--r--r-- 1 0 1 35 Jul 16 1996 README
+lrwxrwxrwx 1 0 1 7 Dec 9 1999 bin -> usr/bin
+dr-xr-xr-x 2 0 1 512 Oct 1 1997 dev
+drwxrwxrwx 2 98 98 512 May 29 16:04 download.html
+dr-xr-xr-x 2 0 1 512 Nov 30 1995 etc
+drwxrwxrwx 2 98 1 512 Oct 30 14:33 pub
+dr-xr-xr-x 5 0 1 512 Oct 1 1997 usr

I checked the logs, and the data that the ftpserver.pl server returns
ends in \r\n, and this is what curl outputs to stdout; but the
<datacheck> section of the data/test215 file is just a regular text file
with \n line endings. Thus the diff of the two fails as above. I don't
understand why this is now failing when it didn't for 7.15.x. Maybe
something has changed that causes curl to no longer remove the trailing
\r on the server's output? In any case there needs to be some way for
the testsuite to deal with this. I use Cygwin in binary mode, which
emulates unix (in that line endings are always \n), so it seems this
should also fail on *nix too, but it must not be if the testsuite passes
there. I noticed that the data/test215 files does contain \r\n line
endings for the section <protocol> at the end, so maybe the <datacheck>
also needs to have \r's embedded to match what ftpserver.pl is sending?

Brian

Index: lib/ldap.c
===================================================================
RCS file: /cvsroot/curl/curl/lib/ldap.c,v
retrieving revision 1.69
diff -u -p -r1.69 ldap.c
--- lib/ldap.c 12 Mar 2007 05:09:25 -0000 1.69
+++ lib/ldap.c 9 Apr 2007 02:16:43 -0000
@@ -58,6 +58,18 @@
 #include "memory.h"
 #include "base64.h"
 
+/* Standard practice on Cygwin is not to include windows.h or any Win32 API
+ * headers, however winldap.h is required to use the LDAP api. This must
+ * happen after #include "urldata.h" otherwise winsock2.h and friends will
+ * get pulled in, leading to lots of problems. */
+#ifdef __CYGWIN__
+# ifndef WIN32_LEAN_AND_MEAN
+# define WIN32_LEAN_AND_MEAN
+# endif
+# include <windows.h>
+# include <winldap.h>
+#endif
+
 #define _MPRINTF_REPLACE /* use our functions only */
 #include <curl/mprintf.h>
 
Index: lib/urldata.h
===================================================================
RCS file: /cvsroot/curl/curl/lib/urldata.h,v
retrieving revision 1.327
diff -u -p -r1.327 urldata.h
--- lib/urldata.h 1 Apr 2007 08:24:23 -0000 1.327
+++ lib/urldata.h 9 Apr 2007 02:16:44 -0000
@@ -228,6 +228,15 @@ typedef enum {
 } curlntlm;
 
 #ifdef USE_WINDOWS_SSPI
+/* Standard practice on Cygwin is not to include windows.h or any Win32 API
+ * headers, however sspi.h will fail without windows.h so we make an exception
+ * here. */
+#ifdef __CYGWIN__
+# ifndef WIN32_LEAN_AND_MEAN
+# define WIN32_LEAN_AND_MEAN
+# endif
+# include <windows.h>
+#endif
 /* When including these headers, you must define either SECURITY_WIN32
  * or SECURITY_KERNEL, indicating who is compiling the code.
  */
Received on 2007-04-09