Hi Michael, I've put a new wcecompat.zip up at essemer.com.au which includes ENOMEM and EAGAIN. The remainder of the problems need to be corrected in OpenSSL.
Regards, Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Wang Sent: Tuesday, 9 August 2005 5:01 AM To: openssl-users@openssl.org Subject: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0 Hi, I downloaded openssl-0.9.8-stable-SNAP-20050805 and compiled it for my Windows CE platform and had a few problems. In general though, the code (for WinCE) has been much improved over the 0.9.8 release; good job openlssl developers! Here are a couple of issues I had. 1. In the CFLAGS define, the compiler didn't like the /wd4959. It said it was unrecognized and refused to go further. So I took it out. 2. cryptlib.c tried to include windows.h, which the compiler could not find. I had to add the following to CFLAGS after the -I$(WCECOMPAT)/include: -I"C:\Program Files\Windows CE Tools\wce420\STANDARDSDK_420\Include\Armv4i" It would probably be better to use macros instead of a hardcoded path like I have for people who are not compiling for Arm or who has installed their eVC++ somewhere else. (But I don't know what those macros are.... sorry). 3. In bf_skey, memcpy was undefined, and /WX caused the compilation to stop. I just took out the /WX flag. But it might be better to actually fix the root cause. If some developer wants to work on this, he can fix the bf_skey file, and when I get the next stable SNAP, I can keep compiling to see what other files generate warnings. 4. lpdir_win.c has ENOMEM undefined. I just added -DENONMEM=1 in CFLAGS. 5. bss_dgram.c has EAGAIN undefined. I just added -DEAGAIN=14 in CFLAGS. 6. r2c_skey.c had an "Internal compiler error". I was reading on MSDN that the arm compiler sometimes blows up trying to optimize loops or something like that. So I took out the /O1i option in CFLAGS. 7. The MFLAGS and probably the LFLAGS need /LIBPATH:$(SDK_LIBPATH), where SDK_LIBPATH is something I added that looks like: SDK_LIBPATH="C:\Program Files\Windows CE Tools\wce420\STANDARDSDK_420\Lib\Armv4i" 8. On that same line, the linker did not like /machine:ARMV4I. Surprisingly, it also threw an error when I changed it to /machine:ARM. It was happy when I changed it /machine:thumb. Not sure how it knew I has compiling for thumb and not vanilla ARM. Somewhere along the line, I saw that for thumb, the following defines are also good: -QRarch4T -DTHUMBSUPPORT -QRinterwork-return I'll have to experiment some more to figure out if these defines are really needed. Michael ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
