[lmi] Multiarch blunders

[Greg Chicares]

[All resolved now; this is just historical documentation.]

As a faltering first step into a brave new multiarch world, I did this, to see
whether I could build the non-GUI parts of lmi with a 64-bit native compiler:

make $coefficiency build_type=native CXXFLAGS='-O2 -ggdb -m64 -fpic 
-Wno-pedantic' CFLAGS='-m64 -fpic' LDFLAGS='-m64' cli_tests

and everything built, but to run the tests I needed to do this:

LD_LIBRARY_PATH='$LD_LIBRARY_PATH:/opt/lmi/src/build/lmi/Linux/gcc/native'

in the zsh chroot session I was using for x86_64-linux-gnu. Then I switched to
a session where I had worked with i686-mingw-w64 builds successfully only
minutes before, and when I made the same target I got this unwelcome message:

boost::filesystem::path: invalid name "Z:" in path: \
  "/opt/lmi/src/build/lmi/Linux/gcc/native/Z:/etc/opt/lmi/default.ill"
Instantiation failed.
[file /opt/lmi/src/lmi/configurable_settings.cpp, line 186]

It seemed "obvious" that the environment variable had oozed from one session
into another. That's not supposed to be possible, and indeed this:

typeset +x LD_LIBRARY_PATH
unset LD_LIBRARY_PATH

in both sessions didn't fix the problem, which I also observed in a brand-new
chroot session. So "obviously" it was some 'wine' thing, hidden so deeply that
I couldn't find it with 'winecfg' or 'env'. I was thinking of reinitializing
'wine' (wiping out everything I had set up), and hoping I wouldn't need to
throw away my whole chroot and create another...but, fortunately, first I went
back and actually read the last line of the error message:

   blah blah blah
   blah blah blah blah blah
   [file /opt/lmi/src/lmi/configurable_settings.cpp, line 186]

and when I looked in /opt/lmi/data/configurable_settings.xml I saw that it
was the means by which the /opt/lmi/.../native/ directory had teleported into
my 'wine' universe. I seem queasily to recall that the configurable_settings
code silently modifies <default_input_filename>. (<print_directory> too, it
would seem.)

Knowing that maintaining builds for multiple architectures in a single chroot
will require a new directory structure anyway, I started thinking that the
same method would solve this problem, too--so I asked myself where the
configurable_settings.xml file should reside. Looking to the GNU project
for a standard answer, I found:

https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
| Data files used by the program during its execution are divided into
| categories in two ways.
|  - Some files are normally modified by programs; others are never
|      normally modified (though users may edit some of these).
|  - Some files are architecture-independent and can be shared by all
|      machines at a site; some are architecture-dependent and can be
|      shared only by machines of the same kind and operating system;
|      others may never be shared between two machines.
| This makes for six different possibilities. However, we want to discourage
| the use of architecture-dependent files, aside from object files and
| libraries. It is much cleaner to make other data files architecture-
| independent, and it is generally not hard.

The author presumably doesn't use msw, but we have to support it, and making
this file architecture-independent seemed hard enough to me that I started
looking for some other way. I thought this might apply:

http://web.mit.edu/Emacs/source/emacs/INSTALL
| - The architecture-independent files go in PREFIXDIR/share/emacs/VERSION
|   (where VERSION is the version number of Emacs, like `19.27').
| - The architecture-dependent files go in
|   PREFIXDIR/libexec/emacs/VERSION/CONFIGURATION
|   (where CONFIGURATION is the configuration name, like mips-dec-ultrix4.2),
|   unless the `--exec-prefix' option says otherwise.

but it seems odd to use libexec for files that are neither libraries nor
executable, and the FHS agrees:

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
| /usr/libexec includes internal binaries that are not intended to be
| executed directly by users or shell scripts.

Of course, the FHS presumes a posix OS, and doesn't have to worry about msw
path representations that lead to incompatibilities like these:

  ----posix----        ----msw----
  $HOME/lmi/print      [directory where the lmi binary resides]
  $HOME/Documents      %USERPROFILE%\My Documents\
  /var/spool           C:\var\spool

Assuming that this was a real problem that the GNU project never had occasion
to solve, I laid out several options:

(1) Ignore the GNU project's advice, and use a scheme like:
  /opt/lmi/data/i686-w64-mingw32/configurable_settings.xml
  /opt/lmi/data/x86_64-w64-mingw32/configurable_settings.xml
  /opt/lmi/data/x86_64-linux/gnu/configurable_settings.xml
Of course, this would require another level of indirection to choose the
appropriate xml file.

(2) Embed path-conversion code like 'winepath' in lmi. That's a repugnant idea,
but...could it be accomplished with boost::filesystem? No: a web search showed
that somebody already tried that, and found that conditional directives cause
exactly one of the posix and msw implementations to be compiled. Simplistically
replacing '\' with '/' and dropping "C:" is no good, because it will doubtless
need a series of refinements that would leave us wishing we had written a
robust implementation in the first place (cygwin is still refining 'cygpath'
after twenty years). And invoking 'cygpath' if it is found, or 'winepath' if it
is found [, or...] is way too cumbersome.

(3) Just use a path that works for all architectures. That's what I used to do
with cygwin, e.g.:
  /var/spool
which worked well enough with msw if I created a "C:\var\spool" directory
beforehand and never switched to a different "drive letter". (End users
probably have something like "C:\whatever".) But this doesn't work well
with wine, whose default drive "C:" is ~/.wine/drive_c while the native
filesystem is on "Z:". (I suppose I could create
  /srv/chroot/cross-lmi/home/greg/.wine/drive_c/var/spool
and write PDF files there, but finding them with GNU/Linux tools in that remote
oddball directory would be a nuisance.)

This was pretty depressing, until I realized that this is a problem that I had
already solved so that msw-native builds could work both natively and with
cygwin, by setting up an "identity mount" that makes the two filesystems look
sufficiently similar that both can accept paths like these:
   /opt/lmi/data/configurable_settings.xml
   /etc/opt/lmi/default.ill
as synonymous. Then PDF files don't wind up in
  chroot/home/greg/.wine/drive_c/var/spool
because they're actually written to
  chroot/var/spool
thanks to a symlink:
  $readlink ~/.wine/drive_c/users/greg/opt/lmi
  ../../../../../../../opt/lmi