[Cryptography-dev] Building cryptography on Windows for Python 3.3

[Alexander Belchenko]

I would be happy to just have some knob to be able to build binaries with
static libs.


2014-02-20 17:30 GMT+02:00 Paul Kehrer <paul.l.kehrer at gmail.com>:

>  We will be offering wheels (32-bit) for the 0.2 release (forthcoming
> today), but as you noted they still require the installation of OpenSSL
> independently. This decision was originally made because we didn’t want to
> get in the business of feeling like we needed to rev cryptography whenever
> OpenSSL did a security release, but maybe we need to revisit that position.
>
> Everyone, time to express some opinions!
>
> -Paul
>
> On Thursday, February 20, 2014 at 2:15 AM, Alexander Belchenko wrote:
>
> IMO, static build is more appropriate for Windows users. That means user
> doesn't need to additionally install openssl binaries.
>
> E.g. CPython itself (ssl standard library) has openssl linked statically
> AFAIK. I suspect this is also to avoid "dll hell". E.g. win64 binary
> installation of OpenSSL has dlls with the exactly same names as win32
> installation: libeay32.dll and ssleay32.dll. I suspect there is no way to
> have both versions co-exists as system-wide dll libraries.
>
> I won't ask you to change your build scripts to use static libs on
> Windows, but I'd like to help with a patch to make this supported in some
> way. I'm going to try to build whl (wheel) file for cryptography with
> static openssl libs for both 32/64. I'm mostly interested in working
> pyOpenSSL library for my project, actually. But it depends on
> `cryptography`.
>
> Any hints on approach to provide support for static build for Windows?
> Probably some sort of config option needed? I'm not sure how it should work
> with pip and wheels.
>
>
> 2014-02-18 16:24 GMT+02:00 Paul Kehrer <paul.l.kehrer at gmail.com>:
>
> Thanks for the information, I don’t believe anyone has ever tried to do a
> static build on Windows before!
>
> Some of the codegen from cffi on the Windows side causes warnings that, to
> our knowledge, are not an issue. We definitely would like to be warning
> clean when compiling with cl.exe (as we are with clang/gcc on OS X and
> Linux).
>
> To run our test suite you should pip install -r dev-requirements.txt and
> then you can run py.test (or tox) to execute the tests.
>
> -Paul Kehrer
>
> On Tuesday, February 18, 2014 at 8:13 AM, Alexander Belchenko wrote:
>
> Hi,
>
> I started to write an email with request for help building cryptography on
> Windows for Python 3.3, but then I figured out how to get the desired
> result, so now I only want to share some knowledge and also provide you a
> build log in the case you're interested in compiler warnings.
>
> Also I'd like to know it built correctly, is there any easy-to-use
> unittest suite I can run? I see there tests package, but I'm not sure what
> is your method to run tests in your project? Obvioulsly `python3 -m
> unittest` does not work.
>
> My intent was to build cryptography library against static libs of OpenSSL
> because I had problems with running simple C code with OpenSSL dlls, I
> found on StackOverflow suggestion that only linking against static
> libraries would help. It does help for me.
>
> Here is openssl directories I've used:
> include: C:\OpenSSL-Win32\include
> lib: C:\OpenSSL-Win32\lib\VC\static
>
> My C code successfully linked against this set of libraries:
> 'libeay32MD', 'ssleay32MD', 'gdi32', 'user32', 'advapi32'
>
> So here is my steps similar to what you wrote on Installation page:
> https://cryptography.io/en/latest/installation/#on-windows
>
> "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86
> set LIB=C:\OpenSSL-Win32\lib\VC\static;%LIB%
> set INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE%
> C:\Python33\python setup.py install
>
> That wasn't enough because of set of libraries you need to link against.
> So I just changed settings in bindings.py:
>
> === modified file cryptography/hazmat/bindings/openssl/binding.py
>
> --- cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:18:03
> +0000
>
> +++ cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:54:26
> +0000
>
> @@ -92,7 +92,9 @@
>
> if sys.platform != "win32":
>
> libraries = ["crypto", "ssl"]
>
> else: # pragma: no cover
>
> - libraries = ["libeay32", "ssleay32", "advapi32"]
>
> + libraries = ["libeay32MD", "ssleay32MD",
>
> + "gdi32", "user32", "advapi32",
>
> + "Ws2_32", "Crypt32"]
>
>  cls.ffi, cls.lib = build_ffi(cls._module_prefix, cls._modules,
>
> _OSX_PRE_INCLUDE, _OSX_POST_INCLUDE,
>
> With the last change I was finally able to build cryptography python
> library. \o/
>
>
> Attached is the build log in the case you want to see compiler errors.
>
> Some warnings catched my eye, like this:
>
> cryptography\hazmat\primitives\__pycache__\_cffi__xcd368b2dx4a8b9ec1.c(218)
> : warning C4244: '=' : conversion from 'unsigned __int64' to 'uint8_t',
> possible loss of data
>
> or
>
> cryptography\hazmat\bindings\__pycache__\_cffi__xabccc2b1x4bab9030.c(4386)
> : warning C4308: negative integral constant converted to unsigned type
>
> Probably you might know that everything is OK, I just wanted to test
> somehow my build is OK.
>
> Alexander.
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
> Attachments:
>  - setup.log
>
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140220/4e6d60aa/attachment-0001.html>