aaargh, sorry I resent bat files instead of txt ones.
here are the promised txt files...
====
Resubmitted with bat scripts as txt files...
rename them as bat to use them, put them in openssl devroot dir.
following is my answer to Andy I just re-submitted with bat files, but
that were rejected by the mail system.
Pierre Delaage
============
Sujet:Re: [PATCH] for openssl v102snap20121213 for WCE 420/WM5/WM6
target platform, to fix compilation issues, resubmitted with bat scripts
De :Pierre DELAAGE <delaage.pie...@free.fr>
Date :17/12/2012 01:00
Pour :Andy Polyakov <ap...@openssl.org>
Copie à :openssl-dev@openssl.org
Dear Andy,
At first I want to say that I am contributing actively to stunnel for
WCE AND W32 (4.34 and now v500b3), using openssl,
exactly following your guidelines for openssl as much as possible :
producing code COMMON to W32 AND WCE as much as possible.
One of the concern I am involved with is also UNICODE AND ANSI versions
of stunnel...
And I am not so bad in win32 programming for years.
You will find my name as contributor here :
https://www.stunnel.org/sdf_ChangeLog.html
Well, that said, common code is just sometimes NOT possible, for fews
things : a lib named differently (ws2.lib for WCE, ws2_32.lib in
W32...comctl32.lib in W32, commctrl in WCE)...
or type missing, but simple to redefined...
For e_capi.c, which is just ONE part of my patch, I AGREE that I should
CHECK and TEST the other code, but I did not have enough time these days,
and I did not understand clearly if that code was in the mainstream
pipeline or not : I do not want to work on a very old version of capi.c.
Anyway I checked rapidly that code, undestood the principle and think
that I can validate or rewrite an equivalent for 1.0.2 in the next weeks.
Yes, yes and yes I try to produce some common code between W32 and WCE,
this is why I think USEFUL to have a folder organisation that allows
coexistence between products of compilation for W32 and WCE.
Without that, when I want to test compilation and execution of various
stunnel version on the same dev host machine (with some emulator for WCE
target), I have to delete openssl files and rebuild them : very painful
because sometimes I go to WCE and then retest on W32 and then go back to
WCE to be sure that a piece of code is working everywhere.
For WCE : you know that you have many processor targets supported by the
EVC compiler: I try to compile FOR MOST OF THEM to be sure TO HAVE the
most general code as possible.
SO it is useful to have a folder organisation that allows X86, ARM, MIPS
compilation products coexistence..along with W32/x86-like processor code
to coexist.
THE TWO missing scripts just SIMPLIFY the compilation process for
WCE/any target AND W32 developers.
I try to put them in that mail as bat file. If that fails I will reput
them as simple text file.
I think they can help: they just implement the guidelines you find in
INSTALL.WCE and INSTALL.W32 files.
*** Something else about compiler : in INSTALL.WCE, one mentions that we
can use EVC3 (outdated), free of charge MS compiler, or above ...:
I am using the EVC420, MS free of charge compiler, to do the job.
In that compiler ....CL.exe is the X86 compiler, CLARM.exe is the name
for the ARM compiler, CLMIPS.exe for MIPS... and so on...
This is like it is....
Why I am using it : because it is FREE of charge. I do not want to pay
for ms tools...
*** For VC-32.pl : there is already a WCE branch, which is normal, BUT
some flags are different from CL.exe to CLARM.exe : this is like it is,
blame MS for that...
=========
Something else : look at VC-32.pl, my patch is correcting a typo ...:
in the original VC-32, line 125, there is written dbg_cLfags instead of
dbg_cFlags...
So when will this be corrected ?
My patch is at least a reminder for other that need openssl on WCE to
what has to be done to get a working openssl lib on WCE (tested with
stunnel),
while waiting for openssl mainstream include some changes for WCE platform.
So at least, an rt number would be a good thing both for others needing
openssl for WCE, and for the memory of the project.
====
Winsock2 : my patch do the job to have common code AND LIB vs winsock :
with my patch, W32 and WCE do the same use of winsock, using winsock2.
In the present code, WCE is using winsock1...and W32 is using winsock2.
My code and VC-32.pl are going in the common sense between w32 and WCE.
=========
Le 16/12/2012 20:37, Andy Polyakov a écrit :
Please! Why is WCE support problematic? Because it's not actively
tested. What one can do? Converge it with platform that is tested more
regularly, "regular" Win32. Is it possible? I see no technical
obstacles. Except for problem of *another* character, namely testing
of the unified code on WCE. This is what we need help with, not more
suggestions for CE-specific code.
I agree completely and try to avoid specific code, but sometimes it is
not possible for little things in general, but THAT SHOULD be considered
anyway. BTW VC-32. pl has already a specific branch for WCE, and so the
existing code, so why not taking in account some more minor changes that
not avoidable, and that will help to stabilize the code for WCE.
My changes are limited but necessary and helpful.
capi. c is apart....and I will have a look at your code.
So question is still if you can confirm if you can compile previously
mentioned e_capi.c as well as just committed
http://cvs.openssl.org/chngview?cn=23126?
I promise to give it a try and let you know. OK.
soon...
As for VC-32.pl and /M* flags. As for `cl 2>&1`. In environments I've
checked it was the matter of which cl is on %PATH%, but it was always
cl. And version in script refers to ARM version, not X86. But there
surely is some reason for question. So what is it? Is your compiler
called something else? This is also something we desperately need help
with, taking consideration various environment factors. Yet, at the
same time we don't want to end up in situation that script works in
very specific configuration. So we need to be creative and keep it
flexible. So it's likely to be more of a dialog and iterations, than
just "path-that-works-for-me-end-of-discussion".
I am happy to HELP. I need also your help to avoid resubmit my patch
every 2 years, for simple code most of the time..a #define somewhere, a
line of code somewhere else.
No, you are wrong : in MS EVC420, cl.exe is for X86 cpu, CLARM.exe for
ARM, CLMIPS.exe...and you also have CLSH.exe for Hitachi processors.
I am not in "path-that-works-for-me-end-of-discussion", but at least I
need an rt number to keep track of discussion and verious iterations on
patch...
But, at a time, I just NEED a working version of openssl, and presently,
I am alone with my code...that is fortunaltely working, not only for me,
as many people are writing to me to get wce support.
To be clear, I DO NOT want to maintain some specific version of openssl
: I would like to count on a mainstream code that I would just to
recompile...
But presently, mainstream openssl is not compiling for WCE.
And I need it.
patch resubmitted WITH no attachment of zip file containing 2 useful
scripts to compile openssl on WCE and W32.
Anyway those 2 scripts are identical to those you can find on v100a
for WCE patch here : http://rt.openssl.org/index.html?q=2350
zips appear corrupted, I can't open them.
I resend those scripts now...but probably the mail will be rejected as
containing bat files.
I am open to further discussion,
Yours sincerely,
Pierre
@echo off
Rem see instructions in openssl\INSTALL.W32
:: usage : myvc32build
:: works with MS VC Express 2008
Title W32 OPENSSL
echo "USAGE : myw32build (some nmake options/targets)"
rem set MS VC env vars
rem ------------------
set isenvok=0
IF DEFINED WindowsSdkDir set /A "isenvok+=1"
if %isenvok%==1 echo W32 ENVIRONMENT OK
if %isenvok%==1 goto envisok
:: if env is NOT ok, set MS VC env vars
:: (this is to avoid repetitive pollution of PATH)
:: some clean up of the environment after possible pollution by other builds
:: but it is safer to re-open a new shell...
set INCLUDE=
echo W32 ENVIRONMENT TO BE ADJUSTED
call "C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat"
:envisok
rem Next you should run Configure:
perl Configure VC-WIN32 no-asm
REM Next you need to build the Makefiles:
call "ms\do_ms"
REM build DLLs and apps :
nmake -f ms\ntdll.mak %1 %2 %3 %4 %5 %6 %7 %8 %9
@echo off
Rem see instructions in openssl\INSTALL.WCE
:: usage : mywcebuild ARMV4|X86|... other targets: see bat scripts in evc/bin
:: Note : adapt EVC/bin/WCE<target>.bat scripts
Title WCE OPENSSL
:: !!!!!!!!!!!!!!
:: CUSTOMIZE THIS according to your EVC INSTALLATION
:: !!!!!!!!!!!!!!
set OSVERSION=WCE420
set PLATFORM=STANDARDSDK
set WCEROOT=C:\Program Files\MSEVC4
set SDKROOT=C:\Program Files\Microsoft SDKs
:: !!!!!!!!!!!!!!!!!!
:: END CUSTOMIZATION
:: !!!!!!!!!!!!!!!!!!
:: Define TARGET CPU
:: -----------------
:: define "new" target (useful if one wants to compile for various WCE target
CPUs)
if "%1"=="" echo "USAGE : mywcebuild TARGETCPU other_make_options..."
if "%1"=="" echo "TARGETCPU=(ARMV4|X86|...), other cpu: see bat scripts in
evc/bin"
if "%1"=="" exit /B
:: old code to default to ARMV4, but it is better that users are WARNED that
the script now need an explicit target!
::if "%1"=="" set NEWTGTCPU=ARMV4
if NOT DEFINED TARGETCPU set TARGETCPU=XXXXX
if NOT "%1"=="" set NEWTGTCPU=%1
if NOT "%1"=="" shift
echo WCE TARGET CPU is %NEWTGTCPU%
rem Adjust MS EVC env vars
rem ----------------------
rem Check MSenv vars against our ref values
set isenvok=0
if "%NEWTGTCPU%"=="%TARGETCPU%" set /A "isenvok+=1"
if %isenvok%==1 echo WCE ENVIRONMENT OK
if %isenvok%==1 goto envisok
:: if env is NOT ok, adjust MS EVC env vars to be used by MS WCE<CPU>.BAT
:: (this is to avoid repetitive pollution of PATH)
echo WCE ENVIRONMENT ADJUSTED
call "%WCEROOT%\EVC\WCE420\BIN\WCE%NEWTGTCPU%.BAT"
:envisok
REM Next indicate where wcecompat is located:
set WCECOMPAT=C:\Users\standard\Documents\Dvts\Contrib\wcecompat\v12\patchedX86
rem Next you should run Configure:
perl Configure VC-CE
REM Next you need to build the Makefiles:
call "ms\do_ms"
REM build DLLs and apps :
"%WCEROOT%\Common\EVC\Bin\nmake" -f ms\cedll.mak %1 %2 %3 %4 %5 %6 %7 %8 %9
