guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile 64-bit Windows support, redux


From: Jonas Hahnfeld
Subject: Re: Guile 64-bit Windows support, redux
Date: Wed, 20 Mar 2024 21:28:54 +0100
User-agent: Evolution 3.50.4

On Wed, 2024-02-07 at 21:29 +0100, Jonas Hahnfeld via Developers list
for Guile, the GNU extensibility library wrote:
> On Wed, 2024-02-07 at 15:23 -0500, Thompson, David wrote:
> > On Wed, Feb 7, 2024 at 3:19 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> > > 
> > > On Wed, 2024-02-07 at 09:19 -0500, Thompson, David wrote:
> > > > On Thu, Jan 4, 2024 at 5:40 AM Jonas Hahnfeld wrote:
> > > > > 
> > > > > On Tue, 2023-11-28 at 22:04 +0100, Jonas Hahnfeld wrote:
> > > > > > 
> > > > > > 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...
> > > > 
> > > > Just chiming in to say this is a very exciting development that I had
> > > > missed when the patch set was first sent!
> > > > 
> > > > Does this allow a fully featured Guile build or are some things still
> > > > disabled? Does JIT work?
> > > 
> > > It's functional enough to run LilyPond (which uses quite a bit of
> > > Guile) and well enough so that there is only one complaint (that I know
> > > of so far) about multiplication with negative numbers not working
> > > right. If I remember correctly from quickly having a look, that's
> > > related to scm_integer_mul_ii using long_magnitude which doesn't quite
> > > work on Windows 64-bit. For LilyPond, we disable some features (JIT,
> > > threading, networking; you can look at the full build recipe here:
> > > https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L628
> > > ) and I don't know which of these would work or how much it would take
> > > to support them.
> > 
> > Ah, bummer. That's a lot of disabled features.  JIT and threads are
> > must-haves for my use-cases.  I guess I'll continue waiting for
> > someone to figure out how to build a fully featured Guile on Windows.
> > Any takers? ;)
> 
> Isn't the common wisdom that you should learn to crawl and walk before
> starting to run? 😉 first we need a booting and working base of Guile
> before the rest can follow at some point. For LilyPond's binaries, we
> disable networking and threads on all platforms so these may just work.
> Regarding the JIT, I think I disabled it right away when I started
> trying to understand what the issues were, so it's possible that the
> state is not actually that dire...

So I can confirm that JIT indeed doesn't work right now on 64-bit
MinGW, but it's relatively easy to fix (first patch). In essence
lightening was getting the calling convention wrong.

Compilation just works --with-threads, as long as bdwgc was built with
--enable-threads=posix to override the automatic detection of win32
threading. I haven't tested if it actually works, but there might be a
good chance.

For the one known issue I mentioned above, the fix is also not too
difficult, just being a bit more careful with mixing scm_t_inum and
long (see second patch).

I'm also explicitly CC'ing Andy and Ludo - we really need a statement
by a maintainer whether this can land. From my point of view, it's a
clear improvement in terms of supported platforms, plus tested by
LilyPond since some time now which is probably one of the bigger
"customers".

Jonas

Attachment: 0001-Fix-lightening-x86_64-Windows-calling-convention.patch
Description: Text Data

Attachment: 0002-Use-inum_magnitude-for-inums.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]