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.


> Jonas