On Tue, 2023-11-28 at 22:04 +0100, Jonas Hahnfeld wrote:
> On Sun, 2023-10-29 at 22:34 +0100, Jonas Hahnfeld wrote:
> > On Tue, 2023-06-06 at 20:50 +0000, Mike Gran wrote:
> > > Hello Guile,
> > 
> > Hi Mike,
> > 
> > I'm sorry for "necrobumping" this thread; I wanted to reply back in
> > June but didn't have enough time to work through what I will explain
> > further below. In any case, I would very much like to see good Windows
> > 64-bit support in Guile to make use of it in LilyPond.
> > 
> > > [...]
> > > 
> > > I'd be willing [1] to update the patches for MinGW support for
> > > review and inclusion into the main branch
> > > for 3.0.10 or 3.2 but, only if maintainers are open, in principle,
> > > to committing the most disruptive patch: the one where all
> > > long integers become intptr_t to deal with Window's stupid
> > > 4-byte longs on 64-bit OSs.  Without agreeing on that as a
> > > possibility, 64-bit Windows support is DOA.
> > 
> > For a long time, I wasn't really convinced by this argument until I
> > realized that the alternative would complicate cross-compilation and
> > move away from the simple {32-bit, 64-bit} x {little-endian, big-
> > endian} matrix for the bytecode.
> > 
> > > There are a couple of slightly outdated versions of janekke's 64-bit patch.
> > > Here, for example:
> > > 
> > > https://git.savannah.gnu.org/cgit/guile.git/commit/?h=wip-mingw&id=76950b4281c7dfff78b9ead6d3d62c070bbc1f13
> > 
> > If I understand correctly, one of the contentious points of this commit
> > (apart from being big and having many changes in one) is that it moves
> > GMP away from long. IIRC there was a statement somewhere that GMP will
> > not change their APIs, which basically means that Guile on Windows
> > would forever be stuck with a quite significantly patched mini-gmp.
> > 
> > I would like to propose a different approach: It turns out to be
> > possible to just define scm_t_inum as intptr_t, while leaving GMP
> > interfaces alone (be that mini-gmp or a full GMP). Instead, the
> > mismatch in type widths can be handled during the conversion to mpz.
> > For a practical implementation, see the fourth patch attached to this
> > message.
> > 
> > Afterwards, the fifth patch takes care of the hashes, which are
> > expected to have the same width as pointers. This is required because
> > (at least) hashes of symbols are stored into the bytecode. Taken
> > together, this seems to enable enough functionality to run LilyPond
> > with Guile 3 on Windows.
> > 
> > What do you and others think of this approach, would this be "more"
> > acceptable to land in main?
> 
> Ping, any comments on this approach? I built binaries for LilyPond
> 2.25.10 using these patches applied on top of Guile 3.0.9 and the
> result seems to work fine on Windows.

Another ping; meanwhile we switched to building the official binaries
of LilyPond with Guile 3.0 starting from version 2.25.11, but it would
be really great to get rid of our downstream patches...

Cheers,
Jonas