Hullo all, Buoyed by early success (read: dumb luck) at getting bzip to build, I thought I'd have a go at gzip. Long story short, I haven't succeeded, but it's raised some interesting questions. GNU gzip - http://www.gnu.org/software/gzip/ - seems to be actively maintained, unlike the stuff at gzip.org, but it depends on Gnulib, which in turn seems to depend on the MinGW runtime.
Gnulib is a bunch of reusable code, which provides implementations of various functionality "missing" from various environments. Unfortunately it isn't a shared library, it really is just a bunch of reusable code: in terms of version control, people either check in a snapshot of the parts they need, or import it using a git submodule (as is the case with gzip), or whatever equivalent their VCS of choice provides. The bigger problem is that it provides a *lot* of autoconf macros for configuring itself to suit the host platform, coupled with making various base assumptions about the host platform's functionality, and I'm not quite sure how we're going to replicate those. Using MinGW and MSYS, it's actually possible to run all the way through gzip's configure script with CC=cl and LD=link, with a bit of environment mangling, but the end result doesn't build. The problem essentially stems from the fact that Gnulib assumes a GNU toolchain and a certain underlying amount of "POSIXness" in the host platform. For example, its replacement for dirent.h - which isn't a static bit of source, but generated locally by autoconf - ended up containing the line '#include_next <dirent.h>', which poses two problems: first of all, the #include_next directive is non-standard and not supported by MSVC; secondly, even if it was supported, the Windows SDK doesn't provide a native dirent.h to begin with. The Gnulib version isn't self-contained, it uses lots of macro trickery to selectively override or augment an existing header. There are also various header files which, once generated, end up containing '#include ""' - I'm not 100% sure what's going on, but I think it's a symptom of a similar problem, where an assumption has been made about the existence of a platform-native header file but the configure script hasn't found one. If I was going to build with the toolchain provided by MinGW itself, this wouldn't be such a problem, because the MinGW runtime library (MinGW-RT) itself meets some of these requirements, but the end goal is to build with MSVC. Unless I've misunderstood the details, I don't think tracing the build would help out here: it would tell us exactly which parts of Gnulib and MinGW-RT get used in the build, but it wouldn't magically fix the problem that the Windows SDK doesn't provide equivalents for all the headers and library functions the code needs. I see several options at this point, but I'm not sure which is best: 1. Port gzip away from Gnulib and MinGW-RT entirely. We would end up with something self-contained and buildable, but the changes would be fairly extensive, and we'd need to repeat the process every time we come across a package with one or both of these dependencies. 2. Support MinGW as an alternative toolchain within CoApp. It's pretty easy to set up these days, and can create executables which run outside the MinGW shell, providing the software doesn't try to do anything too odd at runtime. IMHO a non-starter due to the sheer amount of baggage and maintenance problems this would introduce. 3. Port MinGW-RT to MSVC and package it for CoApp. We may still need MinGW itself to get an initial build of a given package going, but once that's been done & traced, at least we'll have a reasonable assurance that when we swap out the toolchain, we aren't also swapping out great chunks of API which the code relies on. 4. Something else I haven't thought of. I may, of course, be approaching this entirely the wrong way - I do think it will be an ongoing issue, though, because for many developers, MinGW is the toolset of choice when trying to build portable software on Windows. Thoughts? Regards, Phil _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
