linux+mingw -> create openssl for windows [u]

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

linux+mingw -> create openssl for windows [u]

Andreas Jellinghaus-2
My goal: compile opensc, openssl and putty for windows,
but using linux and mingw (on i686 machine, debian sarge).
that way opensc could build nightly binary pacakges for windows.

so, here is a patch for openssl, so it can be compiled with
mingw under linux. no big changes, mostly using the existing
code, changed paths from \ to / and used the i586-mingw32msvc-*
tools (thats how they are called on debian gnu/linux).

install procedure:

wget http://www.openssl.org/source/openssl-0.9.8-beta5.tar.gz
tar xfvz openssl-0.9.8-beta5.tar.gz
cd openssl-0.9.8-beta5
patch -p1 < ../diff5
sh -x ms/mingw32.sh

mkdir -p /opt/win32/openssl
mkdir /opt/win32/openssl/bin
mkdir /opt/win32/openssl/lib
mkdir /opt/win32/openssl/include
mkdir /opt/win32/openssl/include/openssl

cp outinc/openssl/* /opt/win32/openssl/include/openssl
cp out/*.lib /opt/win32/openssl/lib
cp *.dll /opt/win32/openssl/bin
cp out/openssl.exe /opt/win32/openssl/bin

I can't test the result well today (no windows here),but will
do so tomorrow. the resulting binaries are located at
http://www.opensc.org/files/testing/openssl-0.9.8-beta5-win32.tar.gz

I don't know the openssl build system well, so please help me to
fix any bugs I might have in this patch. (it doesn't change any
existing code, only adds new files and a mingwx option.)

Thanks, Andreas

diff5 (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: linux+mingw -> create openssl for windows [u]

Andy Polyakov
> My goal: compile opensc, openssl and putty for windows,
> but using linux and mingw (on i686 machine, debian sarge).
> that way opensc could build nightly binary pacakges for windows.
>
> so, here is a patch for openssl, so it can be compiled with
> mingw under linux. no big changes, mostly using the existing
> code, changed paths from \ to / and used the i586-mingw32msvc-*
> tools (thats how they are called on debian gnu/linux).
>
> install procedure:
>
> wget http://www.openssl.org/source/openssl-0.9.8-beta5.tar.gz
> tar xfvz openssl-0.9.8-beta5.tar.gz
> cd openssl-0.9.8-beta5
> patch -p1 < ../diff5
> sh -x ms/mingw32.sh

- gaswin option is being phased out and should not be used;
- can you confirm that just issuing 'make' right after 'perl Configure
mingwx' doesn't work?
- if you can confirm that it doesn't, can you show how does it fail?

Point is that I'd rather see it cross-built by 'make' [which is known to
work at least under cygwin], than by an extra script. In other words you
should be able to get away with single extra mingwx line to ./Configure
and patch for $exe_ext line... No extra scripts should be required...

> ------------------------------------------------------------------------
>
> diff -udrNP openssl-0.9.8-beta4.orig/Configure openssl-0.9.8-beta4/Configure
> --- openssl-0.9.8-beta4.orig/Configure 2005-06-06 00:19:34.000000000 +0200
> +++ openssl-0.9.8-beta4/Configure 2005-06-19 18:38:18.195835720 +0200
> @@ -474,6 +474,9 @@
>  # MinGW
>  "mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin -shared:.dll.a",
>  
> +# MinGW cross compile
> +"mingwx", "i586-mingw32msvc-cc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin -shared:.dll.a",
> +
>  # UWIN
>  "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32",
>  
> @@ -908,9 +911,9 @@
>  
>  my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds;
>  
> -$IsMK1MF=1 if ($target eq "mingw" && $^O ne "cygwin");
> +$IsMK1MF=1 if ($target eq "mingw" && $^O ne "mingwx" && $^O ne "cygwin");

That's not the way to extend this expression... And how does it help in
your case anyway? Indeed, first comparison is false [in your case] and
IsMK1MF is assigned zero [in your case] regardless $^O... A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: linux+mingw -> create openssl for windows [u]

Andreas Jellinghaus-2
On Monday 20 June 2005 18:48, Andy Polyakov wrote:
> - gaswin option is being phased out and should not be used;
> - can you confirm that just issuing 'make' right after 'perl Configure
> mingwx' doesn't work?
> - if you can confirm that it doesn't, can you show how does it fail?
>
> Point is that I'd rather see it cross-built by 'make' [which is known to
> work at least under cygwin], than by an extra script. In other words you
> should be able to get away with single extra mingwx line to ./Configure
> and patch for $exe_ext line... No extra scripts should be required...

so you want a Configure based approach, but still using mk1mf.pl,
or do you want native Configure / make / make install based system?

I guess the second option, so I tried implementing it. But I need some
help, as the openssl make system is quite complex, and I don't know
all nuances.

The attached diff should be a step in the right direction. but
linking libcrypto.dll fails, as there are still references to:
libcrypto.exp:fake:(.edata+0x2964): undefined reference to
`_ENGINE_load_ubsec'
libcrypto.exp:fake:(.edata+0x2f80): undefined reference to
`_ENGINE_load_cswift'
...
even though I used
-DOPENSSL_NO_HW.

the command that creates this problem is
i586-mingw32msvc-dllwrap --dllname libcrypto.dll \
        --output-lib libcrypto.a \
        --def ms/libeay32.def libcrypto.a \
        -lwsock32 -lgdi32

I guess it has to do with the definition files,
but as I don't know what those exactly do, I'm pretty much lost.

Regards, Andreas
Reply | Threaded
Open this post in threaded view
|

Re: linux+mingw -> create openssl for windows [u]

Andy Polyakov
>>Point is that I'd rather see it cross-built by 'make' [which is known to
>>work at least under cygwin], than by an extra script. In other words you
>>should be able to get away with single extra mingwx line to ./Configure
>>and patch for $exe_ext line... No extra scripts should be required...
>
> so you want a Configure based approach, but still using mk1mf.pl,
> or do you want native Configure / make / make install based system?
>
> I guess the second option,

Correct.

> so I tried implementing it. But I need some
> help, as the openssl make system is quite complex, and I don't know
> all nuances.
>
> The attached diff should be a step in the right direction.

Can you confirm that 'i586-mingw32msvc-cc -shared' can't be used in
place for dllwrap? And if so why? It works under cygwin... Well, apart
from --def stuff... BTW, what is the exact purpose of this project? If
it's not "provide 100% equivalent replacement for .dll built with
Microsoft C," then why bother with --def?

> but
> linking libcrypto.dll fails, as there are still references to:
> libcrypto.exp:fake:(.edata+0x2964): undefined reference to
> `_ENGINE_load_ubsec'
> libcrypto.exp:fake:(.edata+0x2f80): undefined reference to
> `_ENGINE_load_cswift'
> ...
> even though I used -DOPENSSL_NO_HW.

Well, you have to figure this one out yourself. It's likely to be
something trivial such as left-over from previous attempt without
OPENSSL_NO_HW. If your're positive that it's not the case, then 'rm
crypto/engine/eng_all.o', collect output from make and verify if
-DOPENSSL_NO_HW is actually passed down.

> the command that creates this problem is
> i586-mingw32msvc-dllwrap --dllname libcrypto.dll \
>         --output-lib libcrypto.a \
>         --def ms/libeay32.def libcrypto.a \
>         -lwsock32 -lgdi32

libcrypto.a is used as both input and output. Is it actually fool-proof? A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

PATCH: create openssl/windows with mingw/linux [u]

Andreas Jellinghaus-2
here is a working patch so you can create openssl/windows
binaries with linux and mingw. developed and tested on
debian sarge/i686 only.

> BTW, what is the exact purpose of this project?

Currently I'm building "openssl" plus "opensc" plus "putty"
on windows with visual c and it works fine. However I can
do that only here and then and if I could get mingw cross
compiling to work, instead I could do nightly builds.

> If it's not "provide 100% equivalent replacement for .dll built with
> Microsoft C," then why bother with --def?

well, I want to add value, no decrease value by loosing compatiblity.
if I understand mingw right, the result should be compatible, no drawbacks,
right? but also there won't be a *.lib files, as mingw can't create
them.

anyway, here is the latest diff, works for me(tm).
binaries not yet tested.

Install is broken, as those make rules don't know about *.dll.
I use these commands instead:
cp apps/*.dll apps/*.exe apps/openssl.cnf apps/CA.pl /opt/openssl
mkdir /opt/openssl/include
mkdir /opt/openssl/include/openssl
cp include/openssl/*.h /opt/openssl/include/openssl
mkdir /opt/openssl/doc
cp FAQ LICENSE PROBLEMS READM* STATUS NEWS /opt/openssl/doc
cp doc/*.txt doc/*.gif doc/*.html /opt/openssl/doc

Engines are not build. I hacked Configure to call sed on the
engine/Makefile to disable them. I'm sure someone can find
a nice way to do that or get them to compile.

The linking code is very, very ugly.
what about new names for the dlls: libcrypt-0.9.8.dll
and libssl-0.9.8.dll? But also rename any file that
is derived from either "ssleay32" or "libeay32" to those
names, and the code will be clean again. But while openssl
wants to keep those old names for the dlls, the code is
prone to be ugly.

Regards, Andreas