On 2006.10.20 at 12:05:11 +0400, Victor B. Wagner wrote:
> > Can you test if './Configure mingw' followed by 'make
> > CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib' works? I mean
>
> It seems to work. Although when I start make test on real win32 system
Oh, it was with our modified Configure. When I've restarted build with
unmodified 0.9.9 source tree, I got problem with line 933 of Configure
script:
$IsMK1MF=1 if ($target eq "mingw" && $^O ne "cygwin" && !is_msys());
Of course it doesn't recongnize that it should not set IsMK1MF to 1 when
doing Linux-hosted build.
Same problem occurs when doing build with Cygwin compiler, but
non-cygwin (i.e. ActiveState) Perl. And we use this setup on our win32
test machine, so this line was patched in Configure script too.
We have replaced this line in our patched Configure with
my @MK1MF_Builds=qw(VC-WIN64I VC-WIN64A
VC-NT VC-CE VC-WIN32
BC-32 OS2-EMX netware-clib netware-libc
netware-libc-bsdsock);
sMK1MF=scalar grep /^$target$/,@MK1MF_Builds;
It is not perfect to, because it assumes that if one uses mingw32
target, there is always some Unix emulation environment (i.e. cygwin,
msys or real Unix in case of cross-builds).
Function is_msys() as it written, never give correct result in our msys
environments. If I run msys rxvt terminal emulator, TERM is "xterm",
if I start msys shell in console window, it is for some reason "cygwin".
Really, I think checking for existense of TERM variable is enough to
determine that there is some Unix emulation environment. At least, it
can be documented, and user who wants MK1MF build might explicitely
unset this variable during Configure stage without any harm.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
