OK, I downloaded wcecompat 1.1 and openssl-0.9.8-stable-SNAP-20050810 and rebuilt everything again. Things are much, much better now. Of the items below, I think only #2 and #5 suggest a fix is needed in wcecompat and openssl. The others itmes are responses to previous emails.
1. I fixed my %INCLUDE% and %LIB% environment variables to point to the right places. Maybe I installed my SDK in the wrong place or I moved stuff around, I don't remember. But I'm happy to be able to set these environment variables to the right place and the various makefiles find the files they are looking for. 2. wcecompat/wcedefs.mak: I had to add the extra "if" test for TARGETCPU=ARMV4I which I mentioned in a previous email. As to whether the same thing needs to be done if TARGETCPU=ARMV4T, I assume so. i.e. if TARGETCPU is ARMV4T, then ARM, _ARM_, and ARMV4T must be defined. The auto generated ce.mak and cedll.mak seem to do this already. 3. The -DTHUMBSUPPORT I mentioned for the openssl makefile. I don't know where I got that from. I can't find any reference to it. I compiled and ran without it, and it was fine. I think we can forget about this option. 4. The -QRarch4T and -QRinterwork-return I mentioned for the openssl makefile. I was able to build and run without them. However, my both my platformbuilder and embedded visual C++ uses those options for my auto-generated projects, so it seems to me that it would be safer to include them when TARGETCPU=ARMV4I. (-QRarch4T tells the compiler to target code to the ARMV4T architecture. Other options are arch4, arch5, arch5T. I don't know the default. -QRinterwork-return allows function calls to be made across ARM and THUMB code.) 5. I still needed to change the MLFLAGS and LFLAGS in cedll.mak and ce.mak from machine:ARM to machine:thumb. Otherwise, the compiler compains about an incompatibility with winsock.lib (winsock.dll), which was linked with machine:thumb. The compiles go very smoothly now. Its a great improvement over the 0.9.8 release. Thanks for all your help guys! Michael p.s. While I was looking around to figure out the differences among ARM, ARMV4, ARMV4I, and ARMV4T, I found the following, which you may already know: One thing that was really confusing me was that the above monikers are used to describe architectures, as defined by the ARM corporation, and a set of "compilation styles", for a lack of better description, defined by Microsoft. ARM is just a general term. ARMV4 is the oldest supported ARM architecture. It defines a 32 bit instruction set. ARMV4T supports the 32 bit ARMV4 instruction set, plus a new compact 16 bit instruction set called Thumb. ARM processors based on the ARMV4T architecture can switch between the 16-bit thumb instruction set and 32-bit ARM instruction sets. (see http://www.arm.com/products/CPUs/archi-thum.html). WinCE is aware of 3 TARGETCPU types: ARMV4, ARMV4T, and ARMV4I I assumeTARGETCPU=ARMV4 is for the 32 bit ARM processors without the Thumb extensions. I'm not sure exactly when TARGETCPU=ARMV4T is used. Maybe when executables are required to be completely comprised of 32 bit ARM instructions or completely of 16 bit thumb instructions? Or maybe when the entire OS image have to be one or the other? TARGETCPU=ARMV4I allows 32 bit ARM and 16 bit thumb instructions to be mixed at a function level. This TARGETCPU type seems to be meant for ARM CPU's that support the ARMV4T architecture. As of WinCE .NET 4.2, the ARMV4T kernel has been merged into the ARMV4I kernel. As of WinCE 5.0, the ARMV4 kernel has been merged into the ARMV4I kernel. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
