Hello Andy,
Just a comment about "cl 2>&1" in VC-32.pl.
Well this trick is used to check version of "cl".
And you can see that it is checked against values from V14 to V19.
This is clearly related to MS Visual Studio 2005 and above.
That is true that MS Visual Studio starting from 2005 can produce builds
for WCE. But it is only possible with the FULL, money charged, version
of MS Vstudio.
This is not a free of charge tool...
Express versions, as far as I can tell, do not support cross compilation
for WCE.
Anyway, the question is a matter of openssl compilation policy and
consistency between this policy and openssl documentation :
Presently the documentation in INSTALL.WCE file at rootdev folder of
openssl is stating that one can build openssl with standalone free
compiler MS EVC3..
Well, I think evc3 is not anymore able to build openssl, but not 100%
sure...
but this does not matter...
I am using the last free EVC distributed by MS : EVC4 sp4.
It is not any more downloadable from MS (full evc no, but service pack 4
yes...which is useless without the full evc base), but you can find it
at cnet.download.
So what : VC-32 is checking MS compiler from V14 to V19. That does not
mean that other compilers are not ok. EVC4 gives V12 for cl 2>&1.
Please note that even if I compile for ARM, and even if -in EVC- cl
stands for X86 compiler, both compilers are in the PATH so that the test
is anyway "meaning something" to check for compiler version.
eg : both clarm.exe and cl.exe gives V12 in evc4sp4.
If openssl team wants people to use full MS Visual Studio above or equal
to 2005, then INSTALL.WCE file must be corrected.
But that would be a pity, because yes IT IS still possible to compile
openssl with free EVC4.
And it is running perfectly.
Yours sincerely,
Pierre Delaage
Le 17/12/2012 01:08, Pierre DELAAGE a écrit :
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
