[lmi] Problems with the Cygwin build

[Vadim Zeitlin]

 Hello,

 Here is the summary of the problems we've run into while testing the
latest master (caf6f55067448e3ddf9c30b7be5bb7f09fdcfa15) under the latest
version of (64 bit, but I don't think it matters) Cygwin:

1. The already discussed problem with the copy command in
   install_mingw.make makefile. I don't think there is much to add here,
   it can be fixed with the previously mentioned 2 character change as
   done in 
https://github.com/vadz/lmi/pull/107/commits/93670672001fda2da6ef9e999be1059fbbeb3538
   for example.


2. The main problem that took us the longest time to find and that I still
   don't have any real fix for is the build failure with libxml2 due to
   "missing" lzma.h header. The header is, of course, available in
   $local_dir/include (where local_dir=/opt/lmi/gcc-$(LMI_TRIPLET)/local)
   directory and we did pass --with-lzma=$local_dir to libxml2 configure,
   but somehow some weird /usr/i686-w64-mingw32/sys-root/$local_dir/include
   directory ended up being used in the compiler flags instead.

   The confusing thing was that, as I quickly found by looking at
   configure.ac in libxml2 sources, this directory could come either from
   --with-lzma option value, if pkg-config was unavailable, or from
   `pkg-config --cflags liblzma` if it could be used. But the former was
   correct, and the latter... was correct as well!

   I'll spare you the long and stressful story of our hunt for this bug and
   jump straight to the conclusion: the reason libxml2 configure doesn't
   get the right answer from pkg-config is that it's not running
   pkg-config, but rather runs i686-w64-pkg-config, which returns the wrong
   directory path in spite of using the correct liblzma.pc file that was
   installed by our build of liblzma. This is, of course, done
   intentionally by configure and actually makes a lot of sense: when
   cross-compiling, you don't want to use the native libraries installed on
   the system, so when targeting $host, configure tries to use
   $host-prefixed pkg-config, just as it tries to use $host-prefixed
   compiler and other tools on the assumption that it would be better
   suited for returning the path for the libraries compiled for $host.
   And it just so happened, that until very recently (March of this year),
   there was no i686-w64-pkg-config available in Cygwin. However since
   then, pkg-config package in Cygwin was updated from 0.28 or 0.29
   version to version 1.6 and the reason for this dramatic jump in version
   is that pkg-config has now actually become a completely different
   package: it is now pkgconf from http://pkgconf.org/ instead of Free
   Desktop pkg-config. I have no idea why has Cygwin decided to do this,
   but it's not necessarily wrong per se, it just so happens that pkgconf
   comes with support for different "personalities", as they call it, out
   of the box, and provides /usr/bin/i686-w64-pkg-config (and a x86_86
   version too) as part of the package.

   So we now understand perfectly well why does the problem happen, but I
   just don't know how to fix it properly. It looks like lmi, configure and
   pkgconf (under the guise of pkg-config) all do the right thing on their
   own, but it doesn't work together. We could change lmi to install
   liblzma into the directory returned by pkgconf, but this wouldn't work
   with the old pkg-config (not a huge problem, but still an incompatible
   change) and wouldn't be compatible with where we install the other
   libraries. And it doesn't seem right to install lmi libraries outside of
   the lmi directory. But if we don't change the installation location, it
   looks like we must prevent libxml2 configure from using pkgconf to
   locate it. One thing that we can easily do is to just export PKG_CONFIG
   environment variable as it can be used to override configure
   autodetection of pkg-config to use and this is what the commit above
   does and it works, but it's just a hack and I don't think we can really
   consider it as a permanent solution. Unfortunately I can't think of
   anything else neither.

   And this does need to be fixed in some way as otherwise lmi installation
   won't work on any new installation of Cygwin (or any Cygwin updated
   after the beginning of March 2019).


3. It also took us some time to realize it (but this is more of our own
   fault), because the actual problem happened much later during the build
   process due to missing Boost headers, but install_miscellanea.make fails
   if md5sum.exe is not available. IMO the build should just stop at this
   point instead of continuing almost silently (there is an error message
   in the log, but you have to know that it's there to find it). For now
   I've worked around this problem by uploading the old md5sum.exe to
   GitHub as 
https://github.com/vadz/lmi/releases/download/new-cygwin-makefiles/md5sum.exe
   and changing the URL used in this makefile, but this is just a temporary
   solution. It also shouldn't affect building lmi on any system where it
   had been built successfully before as md5sum.exe should be available in
   the cache directory there, so you probably don't need to apply this fix
   immediately -- although you're welcome to if you'd like, of course.


4. Another problem probably not affecting building on any system where lmi
   had been already installed before is also fixed by the commit in the PR
   107 referenced above: /opt/lmi/data directory must exist before we can
   create any files in it.


 That's all for now, I'll try to propose a better fix for the problem (2)
soon (and as soon as I can find it) and we've already discussed the long
term solution to the problem (3).

 Regards,
VZ