openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Michael Wang-7
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Steven Reddie
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Michael Wang
Sent: Tuesday, 9 August 2005 5:01 AM
To: [hidden email]
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                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Michael Wang-7
Oh Hi Steven,

I am pleasently surprised to see that you are monitoring the list.
Thanks for the changes in wcecompat.  I downloaded your latest version
and I also had to make two minor changes for my environment.  I'm not
sure how motivated you are to actually incorporate them....  In any
case, at least it is documented now, so hopefully others can find it.

The first change in wcedefs.mak was for my ARMV4I CPU.  I had to make
sure that _ARM_ and ARM was defined, not just ARMV4I and _ARMV4I_.

The second change in makefile was to add another include line so I can
pick up windows.h.  Not sure why this line was missing from both
wcecompat and openssl compiles.....

The patches are below.

Thanks,
Michael


*** wcedefs.mak Wed Jul 27 14:20:12 2005
--- wcedefs.mak.new Tue Aug  9 10:00:11 2005
***************
*** 62,67 ****
--- 62,71 ----
  WCETARGETCPU=ARM
  WCETARGETCPUDEFS=-DARM -D_ARM_ -D_M_ARM
  WCECC=clarm
+ !ELSEIF "$(TARGETCPU)"=="ARMV4I"
+ WCETARGETCPU=ARM
+ WCETARGETCPUDEFS=-DARM -D_ARM_ -DARMV4I -D_ARMV4I_
+ WCECC=clarm
  !ELSE
  WCETARGETCPU=$(TARGETCPU)
  WCETARGETCPUDEFS=-D$(TARGETCPU) -D_$(TARGETCPU)_
*** makefile Tue Dec  3 00:25:14 2002
--- makefile.new Tue Aug  9 10:00:22 2005
***************
*** 1,6 ****
  !INCLUDE <wcedefs.mak>
 
! CFLAGS=/W3 /WX /Ox /O2 /Ob2 /GF /Gy /nologo $(WCETARGETDEFS)
-DWIN32_PLATFORM_PSPC -DUNICODE -D_UNICODE -DWIN32
-DWIN32_LEAN_AND_MEAN -Iinclude -D_WINDLL -D_DLL /Foobj/
-D_MSC_VER=1200
 
  SRC = \
  src/args.cpp \
--- 1,6 ----
  !INCLUDE <wcedefs.mak>
 
! CFLAGS=/W3 /WX /Ox /O2 /Ob2 /GF /Gy /nologo $(WCETARGETDEFS)
-DWIN32_PLATFORM_PSPC -DUNICODE -D_UNICODE -DWIN32
-DWIN32_LEAN_AND_MEAN -Iinclude -I"C:\Program Files\Windows CE
Tools\wce420\STANDARDSDK_420\Include\Armv4i" -D_WINDLL -D_DLL /Foobj/
-D_MSC_VER=1200
 
  SRC = \
  src/args.cpp \


On 8/8/05, Steven Reddie <[hidden email]> wrote:

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Michael Wang
> Sent: Tuesday, 9 August 2005 5:01 AM
> To: [hidden email]
> 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                    [hidden email]
> Automated List Manager                           [hidden email]
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Andy Polyakov
In reply to this post by Michael Wang-7
> I downloaded openssl-0.9.8-stable-SNAP-20050805 and compiled it for my
> Windows CE platform and had a few problems.

Sometimes "test latest snapshot" *really* means "*latest*":-)

> 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.

This was fixed already.

> 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"

This is expected to be handled by %INCLUDE% environment variable. It's
expected to be set by proper *.BAT script, which you're expected to run
prior you run Configure and nmake in *same* command window.

> 3. In bf_skey, memcpy was undefined,

Will look into it...

> 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.

Steven replied to this.

> 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.

Presumably fixed in latest snapshot. "Presumably" means that it's not
confirmed yet.

> 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"

This is expected to be handled by %LIB% environment variable [see
above]. What were your %INCLUDE% and %LIB% upon nmake time?

> 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

Will be fixed in next snapshot. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Andy Polyakov
In reply to this post by Steven Reddie
Steven,

> 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.

Do you number wcecompat releases? I mean I'd like to mention some
reference point in INSTALL.WCE, e.g. "at least version x.y" or
"downloaded after 8th August 2005." A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Michael Wang-7
In reply to this post by Andy Polyakov
On 8/9/05, Andy Polyakov <[hidden email]> wrote:

> What were your %INCLUDE% and %LIB% upon nmake time?

C:\tmp\newwcecompat\wcecompat>set
CC=clarm.exe
CFG=none
include=C:\Windows CE Tools\WCE420\POCKET PC 2003\include\ARMV4I;C:\Windows CE T
ools\WCE420\POCKET PC 2003\MFC\include;C:\Windows CE Tools\WCE420\POCKET PC 2003
\ATL\include;
lib=C:\Windows CE Tools\WCE420\POCKET PC 2003\lib\ARMV4I;C:\Windows CE Tools\WCE
420\POCKET PC 2003\MFC\lib\ARMV4I;C:\Windows CE Tools\WCE420\POCKET PC 2003\ATL\
lib\ARMV4I;
OSVERSION=WCE420
Path=C:\Program Files\Microsoft eMbedded C++ 4.0\COMMON\EVC\bin;C:\Program Files
\Microsoft eMbedded C++ 4.0\EVC\WCE420\bin;C:\Perl\bin\;C:\WINDOWS\system32;C:\W
INDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Rational\ClearCase\bin;C:\Progr
am Files\Rational\common;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:
\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program Files\Micro
soft Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual Studio\C
ommon\Tools;C:\Program Files\Microsoft Visual Studio\VC98\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PLATFORM=POCKET PC 2003
ProgramFiles=C:\Program Files
SDKROOT=C:\Windows CE Tools
WCECOMPAT=C:\tmp\sslhead\wcecompat
WCEROOT=C:\Program Files\Microsoft eMbedded C++ 4.0

Hmm, my include and lib settings seem close, but not quite right.  But
its good to know that the openssl makefiles use the %INCLUDE% and
%LIB% variables.  At least there is a way to customize the paths
without changing the source files.

Thanks,
Michael
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Andy Polyakov
In reply to this post by Andy Polyakov
>> 3. In bf_skey, memcpy was undefined,
>
> Will look into it...

Looked into it and it didn't make any sense. Required header file is
included so it shouldn't be a problem... Strangely enough there're a
number of files calling memcpy, which are compiled prior bf_skey.c, so
how come it gets "angry" so "late"? I suppose you have to figure this
one out yourself, as it appears as problem with your environment.

>> 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
>
> Will be fixed in next snapshot.

settings.evc4 [provided by Steven] doesn't mention THUMBSUPPORT...
VC-32.pl which will be available in closest snapshot won't contain it
either. Can you actually confirm that THUMBSUPPORT is actually required? A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Steven Reddie
In reply to this post by Andy Polyakov
Hi Andy,

The first release wasn't numbered.  This new release is numbered 1.1.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Andy Polyakov
Sent: Wednesday, 10 August 2005 3:29 AM
To: [hidden email]
Subject: Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Steven,

> 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.

Do you number wcecompat releases? I mean I'd like to mention some reference
point in INSTALL.WCE, e.g. "at least version x.y" or "downloaded after 8th
August 2005." A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Steven Reddie
In reply to this post by Michael Wang-7
The file "C:\Program Files\Microsoft eMbedded C++
4.0\EVC\wce420\bin\WCEARMV4.BAT" should contain a line like:

        if "%WCEROOT%"=="" set WCEROOT=C:\Program Files\Microsoft eMbedded
C++ 4.0

Which is obviously customised on install since the default is "C:\Microsoft
eMbedded C++ 4.0" and I chose to install under Program Files.  If your file
looks different it sounds like you may have installed under a different
directory and manually moved to Program Files.  If that's the case you may
want to move it back, uninstall, then reinstall in the new location as there
are bound to be registry settings (perhaps for the emulator) that point to
the wrong location.

Steven

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Michael Wang
Sent: Wednesday, 10 August 2005 4:51 AM
To: [hidden email]
Subject: Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

On 8/9/05, Andy Polyakov <[hidden email]> wrote:

> What were your %INCLUDE% and %LIB% upon nmake time?

C:\tmp\newwcecompat\wcecompat>set
CC=clarm.exe
CFG=none
include=C:\Windows CE Tools\WCE420\POCKET PC 2003\include\ARMV4I;C:\Windows
CE T ools\WCE420\POCKET PC 2003\MFC\include;C:\Windows CE
Tools\WCE420\POCKET PC 2003 \ATL\include; lib=C:\Windows CE
Tools\WCE420\POCKET PC 2003\lib\ARMV4I;C:\Windows CE Tools\WCE 420\POCKET PC
2003\MFC\lib\ARMV4I;C:\Windows CE Tools\WCE420\POCKET PC 2003\ATL\
lib\ARMV4I; OSVERSION=WCE420 Path=C:\Program Files\Microsoft eMbedded C++
4.0\COMMON\EVC\bin;C:\Program Files \Microsoft eMbedded C++
4.0\EVC\WCE420\bin;C:\Perl\bin\;C:\WINDOWS\system32;C:\W
INDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Rational\ClearCase\bin;C:\Progr
am Files\Rational\common;c:\Program Files\Microsoft SQL
Server\90\Tools\binn\;C:
\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program
Files\Micro soft Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft
Visual Studio\C ommon\Tools;C:\Program Files\Microsoft Visual
Studio\VC98\bin PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PLATFORM=POCKET PC 2003
ProgramFiles=C:\Program Files
SDKROOT=C:\Windows CE Tools
WCECOMPAT=C:\tmp\sslhead\wcecompat
WCEROOT=C:\Program Files\Microsoft eMbedded C++ 4.0

Hmm, my include and lib settings seem close, but not quite right.  But its
good to know that the openssl makefiles use the %INCLUDE% and %LIB%
variables.  At least there is a way to customize the paths without changing
the source files.

Thanks,
Michael
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Steven Reddie
In reply to this post by Andy Polyakov
Whoops, I missed the memcpy reference in the original post.  I added a
memcpy prototype to string.h in wcecompat 1.1 to satisfy an OpenSSL 0.9.8
compile problem, so I guess this is the one.  The problem with the wcecompat
approach is that it overrides/replaces the Microsoft supplied header files.
I made sure that nothing in previous Microsoft implementations was hidden
but it looks like they've moved the memcpy prototype to a different header
file resulting in wcecompat obscuring it.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Andy Polyakov
Sent: Wednesday, 10 August 2005 8:35 AM
To: [hidden email]
Subject: Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

>> 3. In bf_skey, memcpy was undefined,
>
> Will look into it...

Looked into it and it didn't make any sense. Required header file is
included so it shouldn't be a problem... Strangely enough there're a number
of files calling memcpy, which are compiled prior bf_skey.c, so how come it
gets "angry" so "late"? I suppose you have to figure this one out yourself,
as it appears as problem with your environment.

>> 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
>
> Will be fixed in next snapshot.

settings.evc4 [provided by Steven] doesn't mention THUMBSUPPORT...
VC-32.pl which will be available in closest snapshot won't contain it
either. Can you actually confirm that THUMBSUPPORT is actually required? A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Steven Reddie
In reply to this post by Michael Wang-7
I wrote wcecompat solely for the OpenSSL port (but with a view to using it
for other things), so I guess you could say I'm more of an OpenSSL-er than a
Windows CE-er.

Do you know if a similar change needs to be made for ARMV4T?

I believe your include problem below relates to the possible install issue I
mentioned in the other response.  If your %INCLUDE% is set to the wrong
directory then windows.h won't be found.  The fix is to correct %INCLUDE%
(probably by reinstalling eVC4 + SDKs) rather than modify the
wcecompat/OpenSSL makefiles.

Regards,

Steven

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Michael Wang
Sent: Wednesday, 10 August 2005 3:15 AM
To: [hidden email]
Subject: Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Oh Hi Steven,

I am pleasently surprised to see that you are monitoring the list.
Thanks for the changes in wcecompat.  I downloaded your latest version and I
also had to make two minor changes for my environment.  I'm not sure how
motivated you are to actually incorporate them....  In any case, at least it
is documented now, so hopefully others can find it.

The first change in wcedefs.mak was for my ARMV4I CPU.  I had to make sure
that _ARM_ and ARM was defined, not just ARMV4I and _ARMV4I_.

The second change in makefile was to add another include line so I can pick
up windows.h.  Not sure why this line was missing from both wcecompat and
openssl compiles.....

The patches are below.

Thanks,
Michael


*** wcedefs.mak Wed Jul 27 14:20:12 2005
--- wcedefs.mak.new Tue Aug  9 10:00:11 2005
***************
*** 62,67 ****
--- 62,71 ----
  WCETARGETCPU=ARM
  WCETARGETCPUDEFS=-DARM -D_ARM_ -D_M_ARM
  WCECC=clarm
+ !ELSEIF "$(TARGETCPU)"=="ARMV4I"
+ WCETARGETCPU=ARM
+ WCETARGETCPUDEFS=-DARM -D_ARM_ -DARMV4I -D_ARMV4I_ WCECC=clarm
  !ELSE
  WCETARGETCPU=$(TARGETCPU)
  WCETARGETCPUDEFS=-D$(TARGETCPU) -D_$(TARGETCPU)_
*** makefile Tue Dec  3 00:25:14 2002
--- makefile.new Tue Aug  9 10:00:22 2005
***************
*** 1,6 ****
  !INCLUDE <wcedefs.mak>
 
! CFLAGS=/W3 /WX /Ox /O2 /Ob2 /GF /Gy /nologo $(WCETARGETDEFS)
-DWIN32_PLATFORM_PSPC -DUNICODE -D_UNICODE -DWIN32 -DWIN32_LEAN_AND_MEAN
-Iinclude -D_WINDLL -D_DLL /Foobj/ -D_MSC_VER=1200
 
  SRC = \
  src/args.cpp \
--- 1,6 ----
  !INCLUDE <wcedefs.mak>
 
! CFLAGS=/W3 /WX /Ox /O2 /Ob2 /GF /Gy /nologo $(WCETARGETDEFS)
-DWIN32_PLATFORM_PSPC -DUNICODE -D_UNICODE -DWIN32 -DWIN32_LEAN_AND_MEAN
-Iinclude -I"C:\Program Files\Windows CE
Tools\wce420\STANDARDSDK_420\Include\Armv4i" -D_WINDLL -D_DLL /Foobj/
-D_MSC_VER=1200
 
  SRC = \
  src/args.cpp \


On 8/8/05, Steven Reddie <[hidden email]> wrote:
> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Michael Wang
> Sent: Tuesday, 9 August 2005 5:01 AM
> To: [hidden email]
> 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                    [hidden email]
> Automated List Manager                           [hidden email]
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Michael Wang-7
On 8/9/05, Steven Reddie <[hidden email]> wrote:
> I wrote wcecompat solely for the OpenSSL port (but with a view to using it
> for other things), so I guess you could say I'm more of an OpenSSL-er than a
> Windows CE-er.
>
> Do you know if a similar change needs to be made for ARMV4T?
>

Sorry, I don't.  I've been working with Linux/x86 for many years now,
so this is my first foray into the world of ARM and WinCE.  I owe Andy
an answer about some ARM compiler options also.  I'll download the
latest snap this afternoon and try some different options.


> I believe your include problem below relates to the possible install issue I
> mentioned in the other response.  If your %INCLUDE% is set to the wrong
> directory then windows.h won't be found.  The fix is to correct %INCLUDE%
> (probably by reinstalling eVC4 + SDKs) rather than modify the
> wcecompat/OpenSSL makefiles.
>

Yeah, let me try fixing my environment variables and see if that
helps.  I definately don't want to touch the makefiles or source files
if I don't have to.

Thanks,
Michael
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Michael Wang-7
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Steven Reddie
I've put up a wcecompat-1.2 which addresses #2.

ARMV4 is the most common ARM architecture available.  Microsoft called this
"ARM" in eVC3.  Arm defined a Thumb instruction set which is 16-bits to
allow more compact code, with the ability to switch between both modes.
With eVC4 Microsoft renamed "ARM" to "ARMV4" and added "ARMV4T" (for Thumb)
and "ARMV4I" (for Interoperable?, ie. Mixed 32-bit and Thumb code).  ARMV5
is available and I believe that most of the chips in the Windows CE devices
are ARMV5 capable, but ARMV4 has probably been defined as the
lowest-common-denominator -- perhaps the TI OMAP chips used in some of the
Smartphones are only ARMV4.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Michael Wang
Sent: Thursday, 11 August 2005 10:08 AM
To: [hidden email]
Subject: Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

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                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Andy Polyakov
In reply to this post by Michael Wang-7
> 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.

http://cvs.openssl.org/chngview?cn=14356. a.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Michael Wang-7
Thanks Andy!

Michael


On 8/11/05, Andy Polyakov <[hidden email]> wrote:

> > 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.
>
> http://cvs.openssl.org/chngview?cn=14356. a.
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]