status of the Windows port

[libressl]

status of the Windows port

[bcook-r7]

Hi @timkuijsten, LibreSSL 2.1.2 supports building static Windows libraries. The next release will support building DLLs as well (or you can try out a snapshot here). All of the commits from https://github.com/busterb/portable/commits/win32-minimal are already merged into the master here, so I'm unlikely to update that branch.

Since that initial comment on undeadly, I figured out why it was slower as well - my CPU supported the AES-NI instructions, and I was testing AES. LibreSSL currently doesn't build with assembly support on Windows, so of course there was an especially big delta in performance with AES. The current Windows performance shouldn't be much different than LibreSSL 2.1.1 was on other platforms however, since that was before I enabled assembly on POSIX platforms as well.

[timkuijsten]

@bcook-r7 tnx for the super quick update!

There is a question about mingw compatibility with the VS compiler/linker. I'm not sure if that is something you're dealing with as well. But if so, maybe you could elaborate a bit on that? (I'm not a system programmer, nor Windows user, just someone that would love to see io.js ship with LibreSSL and it's new tls API).

[bcook-r7]

I haven't tried it, but this may be useful as a guide: https://wiki.videolan.org/GenerateLibFromDll

[zsszatmari]

Hi! I just tried to compile libressl with mingw32 & msys, most recent versions (according to mingw-get, that is). ./configure ran without problems, but actual compile did not:

CC aes/libcrypto_la-aes_core.lo
In file included from c:\mingw\include\sys\stat.h:37:0,
from ../include/stdlib.h:11,
from aes/aes_core.c:38:
../include/sys/types.h:14:24: fatal error: _bsd_types.h: No such file or directory
#include <_bsd_types.h>

If I did something wrong, any help would be appreciated!

[busterb]

@zsoltt I test with http://mingw-w64.sourceforge.net/ which, contrary to its name, actually includes 32-bit and 64-bit toolchains. I believe that mingw32 is a bit out of date compared to mingw-w64.

The easiest way to get these compilers IMO is to actually install them with cygwin. Then you don't really need msys either. Then I configure with a command like this:

CC=i686-w64-mingw32-gcc ./configure --host=i686-w64-mingw32

[zsszatmari]

Thanks for the quick answer! I wasn’t aware of this, now I feel enlightened.

On Sat, Jan 24, 2015 at 6:24 PM, Brent Cook [email protected]
wrote:

@zsoltt I test with http://mingw-w64.sourceforge.net/ which, contrary to its name, actually includes 32-bit and 64-bit toolchains. I believe that mingw32 is a bit out of date compared to mingw-w64.
The easiest way to get these compilers IMO is to actually install them with cygwin. Then you don't really need msys either. Then I configure with a command like this:

CC=i686-w64-mingw32-gcc ./configure --host=i686-w64-mingw32

Reply to this email directly or view it on GitHub:
#59 (comment)

[busterb]

I just added a file for building windows libraries and adjusting the headers so they can work with visual studio. It requires a fair amount of software pre-installed (VS 2013, cygwin, mingw packages), but we may use it later to simply provide binary packages:
https://github.com/libressl-portable/portable/blob/master/dist-win.sh

At any rate, I'm going to close this ticket for now, though feel free to comment on any issues you have.

[timkuijsten]

In the 2.1.4 release notes I read

This release also includes a binary package for convenience integrating LibreSSL on Windows platforms, and the latest source tarball is signed with GPG and signify for easier integration into existing build systems.

Would this be a possible solution for the concerns raised in the io.js issue?