coapp-developers team mailing list archive

[Philip Allison <mangobrain@xxxxxxxxxxxxxx>]

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