LilyPond 2.16+ on WINE 1.0

[Silas S. Brown]

Hi, I'm trying to set up a recent LilyPond on someone's old
laptop.  Because of the laptop's age, it has trouble running
modern Linux distros.  The best distro I've managed to put on
it is Debian Sarge (released in 2005) with the Linux 2.4 kernel.
An additional complication is the location is a 16-hour round
trip away and does not have an Internet connection, so I want
an approach that's likely to work first time.  (I can however
test things in VirtualBox before I go.)  Upgrading the hardware
is not likely to be a well-received approach.

My options are:

  1.  Install Sarge's lilypond package and related software
       - this will leave the user stuck in 2005 with LilyPond 2.2.6.

  2.  Try to compile all the prerequisites for a newer LilyPond
       - this is a headache because so much is outdated on Sarge
       (even the version of Python is too old), and you can't even
       get a recent enough version of gcc without bootstrapping it.

  3.  Try to run a newer distro in a chroot environment
      - but how long would it be before I hit something that
      doesn't get on well with that old 2.4 kernel?

  4.  Use WINE.

LilyPond's Windows version bundles everything, and it ought to
be fairly straightforward to run on WINE, especially if we limit
it to command-line only.

It seems that the most recent version of WINE that can possibly
be compiled for the 2.4 kernel is WINE 1.0 (2008).  More recent
WINEs require the pthreads support from 2.6, and it's a LOT of
hassle to patch that out.  So I'm now trying to get LilyPond
working on WINE 1.0.

I tried both 2.16.2 and 2.17.17.  With both, I managed to
process a .ly file and output a MIDI file, but then when it
tries to write the PostScript it crashes on:

fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
...framework-ps.scm:449:22: requested file mode not available on fdes

The Scheme code was simply doing (open-file filename "wb")
(and no, changing it to "w", "w+" or "w+b" does not stop crash).
The "not available" text is in libguile-17.dll, in Guile's
fports.c in the function scm_i_fdes_to_port() which is not
accepting the return value of getflags() on the open file.

(An empty .ps file was in fact created, so opening the file
itself is not the problem.  0x01b6 is the hex representation of
octal 0666 which is used in scm_open_file's syscall to open or
open64; it's fair enough that this is ignored.  Adding a native
msvcrt.dll doesn't help - WINE 1.0 won't load it because so
many of its dependent DLLs are missing.)

getflags() should be returning fstat()'s .st_mode, and
scm_i_fdes_to_port tests only its bottom 2 bits (&=O_ACCMODE i.e. 3)
before raising that error.  The only way this should happen is if
fstat is somehow setting .st_mode to 0 but not returning error.

That's as far as I can go without cross-compiling a patched
version of Guile (which is doable but slightly fiddly; it has 2
prerequisites and you have to set up MingW in the way it expects,
or patch its build scripts).

I'm not sure which part of LilyPond opens the MIDI file for writing
(it doesn't seem to be any of the Scheme code); the above problem
encountered when writing the PostScript does not apply to MIDI.

I tried changing (open-file filename "wb") in framework-ps.scm
to (current-output-port) and doing lilypond music.ly | cat > out.ps
(the cat is necessary to stop the file being truncated for some
reason), but the resulting PostScript won't render, probably because
stdout is not open in binary mode.  And I can't seem to find any
obvious way of bypassing scm_i_fdes_to_port (with its check) from Scheme.

Guile 2.0+ has totally different checking code, but I'm not sure
if it would work to overwrite the libguile-17.dll with a
libguile-2.0-22.dll or something (if I could find one).

Does anyone know how to solve this?  Otherwise I might just
have to settle for LilyPond 2.2.6 in Debian Sarge.

(As an experiment, I tried installing LilyPond 2.12.3 on WINE 1.0
and got the same problem, so we can't just go back a few versions
to avoid it.  MuseScore 1.3 seems to work on WINE 1.0 but I'm
not very good at using it.)

Thanks.

Silas


-- 
Silas S Brown http://people.ds.cam.ac.uk/ssb22