On Wed, Oct 22, 2014 at 07:28:40PM -0500, Brent Cook wrote: > 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: > > > > [snip] > > > > 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).
This is similar to my local modifications, most of which I have yet to exhaustively test. So far I've not modified any of the automake inputs. > 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. Ah, I'd forgotten about that. Perhaps using a method of logging that delegates to the application using a callback, and on POSIX have a default handler that goes to syslog? Then, on Linux one could use a handler for the systemd journal, and on Windows the app would have to deal with it. I would think that asking the library to set the handler back to NULL would mean "use platform default" in this instance, but I can also see how that might not be considered a great idea. > 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. My personal preference has typically been to jettison autotools (it's always a big headache even when you've been using it for 10+ years, IMHO) and use GNU make; then I simply structure things with a small receipe generator that creates rules for all platforms I support, and builds the software for all supported platforms in a single "make" invocation. This method wouldn't work here, of course. The important piece is this: I have 'common' source files, 'posix' source files, and 'windows' source files. I will use #ifdefs in common files only when wrapping one or two lines. I move headers to a single project-wide include so that I don't have to manage #ifdef soup in the headers for the whole project. Major point being, I'd very much like to ensure as close to full support for Windows as possible. It is my intent to be able to use LibreSSL in all of my portable projects so that I only need to worry about programming to exactly one interface. --- Mike -- Michael B. Trausch Fortified Tech Systems LLC P: (404) 692-6078 or (844) GR8-TECH (Toll Free)
