On Wed, Oct 22, 2014 at 4:02 PM, Ted Unangst <t...@tedunangst.com> wrote:
> On Wed, Oct 22, 2014 at 16:07, Michael B. Trausch wrote: > > > I have done a very ugly port that builds and works in the few > > scenarios that I've tested with, but it's not complete as some > > features (mostly the ones that allow disabling at compile time) need > > more work to finish porting. > > I think the first piece is of course the necessary build files. Access > to Windows machines isn't really a problem, so sorting out the > necessary ifdefs or other changes can be done on a case by case basis, > but first we need the infrastructure in place to start feeding > everything into the compiler. > > It sounds like you already have this. Makefiles? Posting those files > somewhere would be a great start, and since it's entirely independent of > existing code it can be integrated fairly easily even if it doesn't > build without further changes. > With mingw as the target, most of the code already builds with no other changes, and automake does the trick. I just built it with a mingw cross-compiler using: ./configure --host=i686-w64-mingw32 about 15 files need updates, largely in libcrypto/bio and openssl(1). https://gist.github.com/busterb/f36aa6de0ea47542aa41 Some parts, like b_log.c, do not seem to have much use as part of a Windows port beyond just being stubbing out. In that particular case, writing to the Windows event log, as OpenSSL does, does not have much value if you don't have an accompanying resource object built into your binary (e.g. a static library), so that is already mostly broken in OpenSSL anyway. If we wanted to be slightly more cavalier and adopt something close to BoringSSL's bio subsystem (adding back the parts it jettisoned for compatibility), there is already reasonable Windows support there, IMO. The portable libressl releases have tried to push the compatibility > changes out of the main sources, confining them to isolated platform > specific files, but I recognize that the Windows changes may be more > extensive. I think our strategy will be to include some minor ifdefs > where necessary, or to copy files in other cases. i.e., socket.c may > become winsocket.c. We're trying to avoid too much interleaving within > individual files. > > Would we possibly split files on boundaries where the common and uncommon bits are grouped more closely? I believe we did something like that with arc4random to make porting easier and reduce the number of #ifdefs to a minimum. The BoringSSL versions do have some minimal #ifdefs.
