guix-build---target=x86_64-w64-mingw32 #90

janneke commented 2026年01月06日 17:11:08 +01:00

These patches actually enable a mingw build with guix (it puzzels me a bit that mingw patches were merged without providing a way to test them?) and show that:

guix build -f guix.scm --target=x86_64-w64-mingw32

fails with:

...
../lib/verify.h:213:41: error: static assertion failed: "verify (SCM_MOST_POSITIVE_FIXNUM <= (mp_limb_t) -1)"
 213 | # define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC)
 | ^~~~~~~~~~~~~~
../lib/verify.h:305:20: note: in expansion of macro '_GL_VERIFY'
 305 | # define verify(R) _GL_VERIFY (R, "verify (" #R ")", -)
 | ^~~~~~~~~~
integers.c:41:1: note: in expansion of macro 'verify'
 41 | verify (SCM_MOST_POSITIVE_FIXNUM <= (mp_limb_t) -1);
 | ^~~~~~
integers.c: In function 'scm_integer_ceiling_quotient_iz':
integers.c:786:36: warning: overflow in conversion from 'long long int' to 'long int' changes value from '2305843009213693952' to '0' [-Woverflow]
 786 | bignum_cmp_long (y, -SCM_MOST_NEGATIVE_FIXNUM) == 0)
...

They do work, however on

https://codeberg.org/janneke/guile/commits/branch/wip-mingw-2026

which is based on

https://codeberg.org/spk121/guile/commits/branch/wip-mingw-2026

Which is nice, but next up would be a way to actually test if what has been built actually works, something like

https://codeberg.org/janneke/guile/commit/a481d157d93b9999b687f98c7d8c98997e1044a8

I'll be looking at that next for =wip-mingw-2026=, which interestingly, "lacks" the huge x86_64-mingw32 commit that we've been working with for years.

These patches actually enable a mingw build with guix (it puzzels me a bit that mingw patches were merged without providing a way to test them?) and show that: ``` guix build -f guix.scm --target=x86_64-w64-mingw32 ``` fails with: ``` ... ../lib/verify.h:213:41: error: static assertion failed: "verify (SCM_MOST_POSITIVE_FIXNUM <= (mp_limb_t) -1)" 213 | # define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC) | ^~~~~~~~~~~~~~ ../lib/verify.h:305:20: note: in expansion of macro '_GL_VERIFY' 305 | # define verify(R) _GL_VERIFY (R, "verify (" #R ")", -) | ^~~~~~~~~~ integers.c:41:1: note: in expansion of macro 'verify' 41 | verify (SCM_MOST_POSITIVE_FIXNUM <= (mp_limb_t) -1); | ^~~~~~ integers.c: In function 'scm_integer_ceiling_quotient_iz': integers.c:786:36: warning: overflow in conversion from 'long long int' to 'long int' changes value from '2305843009213693952' to '0' [-Woverflow] 786 | bignum_cmp_long (y, -SCM_MOST_NEGATIVE_FIXNUM) == 0) ... ``` They do work, however on ``` https://codeberg.org/janneke/guile/commits/branch/wip-mingw-2026 ``` which is based on ``` https://codeberg.org/spk121/guile/commits/branch/wip-mingw-2026 ``` Which is nice, but next up would be a way to actually test if what has been built actually works, something like ``` https://codeberg.org/janneke/guile/commit/a481d157d93b9999b687f98c7d8c98997e1044a8 ``` I'll be looking at that next for =wip-mingw-2026=, which interestingly, "lacks" the huge x86_64-mingw32 commit that we've been working with for years.

michaelkaeppler commented 2026年01月08日 21:22:05 +01:00

@hahnjo is the much more competent person to comment on the changes made in #22, but IIUC the error you mentioned could be caused by the part that we patched on Lilypond's side and which is missing in #22 - changing mini-gmp to use long long as its limb type (as proposed in #86)

Which commit do you refer to by 'huge x86_64-mingw32 commit that we've been working with for years'?

@hahnjo is the much more competent person to comment on the changes made in https://codeberg.org/guile/guile/pulls/22, but IIUC the error you mentioned could be caused by the part that we patched on Lilypond's side and which is missing in #22 - changing mini-gmp to use `long long` as its limb type (as proposed in https://codeberg.org/guile/guile/pulls/86) Which commit do you refer to by 'huge x86_64-mingw32 commit that we've been working with for years'?

janneke commented 2026年01月08日 23:36:13 +01:00

Yes #22 could very well be the patch that fixes this build. Still, I believe it's nice to have a recipe like this that can assert if the build succeeds or not, even if (or esp if?) it doesn't succeed just yet?

This is the patch we've been using that i referred to

https://codeberg.org/spk121/guile/commit/a043eaf349e151efb114f9363f8080956687ca46

Yes #22 could very well be the patch that fixes this build. Still, I believe it's nice to have a recipe like this that can assert if the build succeeds or not, even if (or esp if?) it doesn't succeed just yet? This is the patch we've been using that i referred to ``` https://codeberg.org/spk121/guile/commit/a043eaf349e151efb114f9363f8080956687ca46 ```

hahnjo commented 2026年01月11日 21:38:53 +01:00

@janneke wrote in #90 (comment):

It puzzels me a bit that mingw patches were merged without providing a way to test them?

The patches upstreamed in #22 are tested since two years in LilyPond's binaries and I also tested the PR using that infrastructure. I personally don't use Guix and I'm not very interested in trying it out...

guix build -f guix.scm --target=x86_64-w64-mingw32

fails with:

...
../lib/verify.h:213:41: error: static assertion failed: "verify (SCM_MOST_POSITIVE_FIXNUM <= (mp_limb_t) -1)"
 213 | # define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC)
 | ^~~~~~~~~~~~~~
../lib/verify.h:305:20: note: in expansion of macro '_GL_VERIFY'
 305 | # define verify(R) _GL_VERIFY (R, "verify (" #R ")", -)
 | ^~~~~~~~~~
integers.c:41:1: note: in expansion of macro 'verify'
 41 | verify (SCM_MOST_POSITIVE_FIXNUM <= (mp_limb_t) -1);
 | ^~~~~~
integers.c: In function 'scm_integer_ceiling_quotient_iz':
integers.c:786:36: warning: overflow in conversion from 'long long int' to 'long int' changes value from '2305843009213693952' to '0' [-Woverflow]
 786 | bignum_cmp_long (y, -SCM_MOST_NEGATIVE_FIXNUM) == 0)
...

As @michaelkaeppler wrote, the issue with mini-gmp should be solved with #86. For the moment, main should only work with "regular" GMP which already uses long long limb by default (not tested recently though).

I'll be looking at that next for =wip-mingw-2026=, which interestingly, "lacks" the huge x86_64-mingw32 commit that we've been working with for years.

AFAICT the commit has been split up, janneke/guile@b4e0321d2c "Allow modificaton of base long type in mini-gmp" contained in the branch and proposed in #81 still modifies mini-gmp in a way that would fundamentally diverge from upstream and "regular" GMP in terms of function signatures. That's the whole idea behind #22 that we "just deal with it". As said elsewhere, that's not fully done yet and there are some remaining issues, follow-up work is needed for this.

@janneke wrote in https://codeberg.org/guile/guile/pulls/90#issue-3148604: > It puzzels me a bit that mingw patches were merged without providing a way to test them? The patches upstreamed in https://codeberg.org/guile/guile/pulls/22 are tested since two years in LilyPond's binaries and I also tested the PR using that infrastructure. I personally don't use Guix and I'm not very interested in trying it out... > ```text > guix build -f guix.scm --target=x86_64-w64-mingw32 > ``` > > fails with: > > ```text > ... > ../lib/verify.h:213:41: error: static assertion failed: "verify (SCM_MOST_POSITIVE_FIXNUM <= (mp_limb_t) -1)" > 213 | # define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC) > | ^~~~~~~~~~~~~~ > ../lib/verify.h:305:20: note: in expansion of macro '_GL_VERIFY' > 305 | # define verify(R) _GL_VERIFY (R, "verify (" #R ")", -) > | ^~~~~~~~~~ > integers.c:41:1: note: in expansion of macro 'verify' > 41 | verify (SCM_MOST_POSITIVE_FIXNUM <= (mp_limb_t) -1); > | ^~~~~~ > integers.c: In function 'scm_integer_ceiling_quotient_iz': > integers.c:786:36: warning: overflow in conversion from 'long long int' to 'long int' changes value from '2305843009213693952' to '0' [-Woverflow] > 786 | bignum_cmp_long (y, -SCM_MOST_NEGATIVE_FIXNUM) == 0) > ... > ``` As @michaelkaeppler wrote, the issue with `mini-gmp` should be solved with https://codeberg.org/guile/guile/pulls/86. For the moment, `main` should only work with "regular" GMP which already uses `long long` limb by default (not tested recently though). > I'll be looking at that next for =wip-mingw-2026=, which interestingly, "lacks" the huge x86_64-mingw32 commit that we've been working with for years. AFAICT the commit has been split up, https://codeberg.org/janneke/guile/commit/b4e0321d2c8b84edf08b8a2c2c025e5db1dc9798 "Allow modificaton of base long type in mini-gmp" contained in the branch and proposed in https://codeberg.org/guile/guile/pulls/81 still modifies `mini-gmp` in a way that would fundamentally diverge from upstream and "regular" GMP in terms of function signatures. That's the whole idea behind https://codeberg.org/guile/guile/pulls/22 that we "just deal with it". As said elsewhere, that's not fully done yet and there are some remaining issues, follow-up work is needed for this.

janneke commented 2026年01月12日 13:49:30 +01:00

@hahnjo wrote in #90 (comment):

@janneke wrote in #90 (comment):

It puzzels me a bit that mingw patches were merged without providing a way to test them?

The patches upstreamed in #22 are tested since two years in LilyPond's binaries and I also tested the PR using that infrastructure.

Okay great, but wouldn't it be nice for others, like me, to be able to easily replicate that?

I personally don't use Guix and I'm not very interested in trying it out...

Ah, sure; I understand. I guess it's unreasonable to expect that a simple reproducible cross build instruction like

guix build -f guix.scm --target=x86_64-w64-mingw32

could easily be shared without [wanting to/knowing how to use] Guix.

As @michaelkaeppler wrote, the issue with mini-gmp should be solved with #86. For the moment, main should only work with "regular" GMP which already uses long long limb by default (not tested recently though).

Ah, I missed that bit; thanks!

I'll be looking at that next for =wip-mingw-2026=, which interestingly, "lacks" the huge x86_64-mingw32 commit that we've been working with for years.

AFAICT the commit has been split up, janneke/guile@b4e0321d2c "Allow modificaton of base long type in mini-gmp" contained in the branch and proposed in #81 still modifies mini-gmp in a way that would fundamentally diverge from upstream and "regular" GMP in terms of function signatures. That's the whole idea behind #22 that we "just deal with it". As said elsewhere, that's not fully done yet and there are some remaining issues, follow-up work is needed for this.

Thanks! I also managed to miss that. Before, mini-gmp was required for MinGW so I didn't even consider that. I was somehow looking for commits marked MinGW, but this splitting-up is beautiful! The huge commit was pretty awkward and possibly another reason why the cross-build wasn't merged sooner.

So, I've amended this patch series with a "--disable-mini-gmp" commit (that can be easily reverted once #22 gets merged), and also added "--without-64-calls" for MinGW. I'm not sure this is what we want, IWBN if configure made the right choice?

Anyway, this patch set now produces a MinGW binary.

@hahnjo wrote in https://codeberg.org/guile/guile/pulls/90#issuecomment-9744014: > @janneke wrote in #90 (comment): > > > It puzzels me a bit that mingw patches were merged without providing a way to test them? > > The patches upstreamed in #22 are tested since two years in LilyPond's binaries and I also tested the PR using that infrastructure. Okay great, but wouldn't it be nice for others, like me, to be able to easily replicate that? > I personally don't use Guix and I'm not very interested in trying it out... Ah, sure; I understand. I guess it's unreasonable to expect that a simple reproducible cross build instruction like > > guix build -f guix.scm --target=x86_64-w64-mingw32 could easily be shared without [wanting to/knowing how to use] Guix. > As @michaelkaeppler wrote, the issue with `mini-gmp` should be solved with #86. For the moment, `main` should only work with "regular" GMP which already uses `long long` limb by default (not tested recently though). Ah, I missed that bit; thanks! > > I'll be looking at that next for =wip-mingw-2026=, which interestingly, "lacks" the huge x86_64-mingw32 commit that we've been working with for years. > > AFAICT the commit has been split up, [`janneke/guile@b4e0321d2c`](https://codeberg.org/janneke/guile/commit/b4e0321d2c8b84edf08b8a2c2c025e5db1dc9798) "Allow modificaton of base long type in mini-gmp" contained in the branch and proposed in #81 still modifies `mini-gmp` in a way that would fundamentally diverge from upstream and "regular" GMP in terms of function signatures. That's the whole idea behind #22 that we "just deal with it". As said elsewhere, that's not fully done yet and there are some remaining issues, follow-up work is needed for this. Thanks! I also managed to miss that. Before, mini-gmp was required for MinGW so I didn't even consider that. I was somehow looking for commits marked MinGW, but this splitting-up is beautiful! The huge commit was pretty awkward and possibly another reason why the cross-build wasn't merged sooner. So, I've amended this patch series with a "--disable-mini-gmp" commit (that can be easily reverted once #22 gets merged), and also added "--without-64-calls" for MinGW. I'm not sure this is what we want, IWBN if configure made the right choice? Anyway, this patch set now produces a MinGW binary.

ArneBab commented 2026年01月24日 14:22:50 +01:00

@hahnjo @janneke there are two PRs for lightening on Windows. Could you have a look whether they match the ideas you have for the path forward or conflict with work done here and patches that are already in lilypond?

guile/lightening#1
guile/lightening#2

I’m asking you because I don’t know the area and can’t test it, but changes in lightening are likely to eventually end up in Guile, so that’s the only way I see to keep the Windows work coherent. I hope that’s OK for you!

@hahnjo @janneke there are two PRs for lightening on Windows. Could you have a look whether they match the ideas you have for the path forward or conflict with work done here and patches that are already in lilypond? https://codeberg.org/guile/lightening/pulls/1 https://codeberg.org/guile/lightening/pulls/2 I’m asking you because I don’t know the area and can’t test it, but changes in lightening are likely to eventually end up in Guile, so that’s the only way I see to keep the Windows work coherent. I hope that’s OK for you!

janneke commented 2026年04月06日 16:48:55 +02:00

It's a good suggestion, but let's keep this one patch at a time.

This pull request enables anyone (who isn't opposed to using guix) with a guix recipe to verify the mingw build.

It's a good suggestion, but let's keep this one patch at a time. This pull request enables anyone (who isn't opposed to using guix) with a guix recipe to verify the mingw build.

janneke commented 2026年04月06日 16:53:47 +02:00

It's a good suggestion, but let's keep this one patch at a time.

This pull request enables anyone (who isn't opposed to using guix) with a guix recipe to verify the mingw build.

It's a good suggestion, but let's keep this one patch at a time. This pull request enables anyone (who isn't opposed to using guix) with a guix recipe to verify the mingw build.

janneke commented 2026年04月06日 16:56:21 +02:00

It's a good suggestion, but let's keep this one patch at a time.

This pull request enables anyone (who isn't opposed to using guix) with a guix recipe to verify the mingw build.

It's a good suggestion, but let's keep this one patch at a time. This pull request enables anyone (who isn't opposed to using guix) with a guix recipe to verify the mingw build.

michaelkaeppler commented 2026年04月09日 22:30:26 +02:00

I can confirm that this patch enables to produce a Guile executable when cross-compiling
for the x86_64-w64-mingw32 target. The resulting binary will not run without further fiddling
with the search path or copying DLLs to the bin directory, however.
(or maybe I'm just doing something wrong)

I propose #163 to address this issue, which builds on your PR. #163 allows me to create a package
whose guile executable is ready to be under wine out of the box.

I can confirm that this patch enables to produce a Guile executable when cross-compiling for the `x86_64-w64-mingw32` target. The resulting binary will not run without further fiddling with the search path or copying DLLs to the bin directory, however. (or maybe I'm just doing something wrong) I propose #163 to address this issue, which builds on your PR. #163 allows me to create a package whose `guile` executable is ready to be under `wine` out of the box.

janneke commented 2026年04月10日 06:57:27 +02:00

@michaelkaeppler wrote in #90 (comment):

I can confirm that this patch enables to produce a Guile executable when cross-compiling for the x86_64-w64-mingw32 target.

That's great, thanks!

The resulting binary will not run without further fiddling with the search path or copying DLLs to the bin directory, however. (or maybe I'm just doing something wrong)

Yes, you're right.

I propose #163 to address this issue, which builds on your PR. #163 allows me to create a package whose guile executable is ready to be under wine out of the box.

Nice! Possibly we'l want the libraries to be propagated-inputs for mingw instead of symlinking them manually but we can address that in #163

@michaelkaeppler wrote in https://codeberg.org/guile/guile/pulls/90#issuecomment-12930270: > I can confirm that this patch enables to produce a Guile executable when cross-compiling for the `x86_64-w64-mingw32` target. That's great, thanks! > The resulting binary will not run without further fiddling with the search path or copying DLLs to the bin directory, however. (or maybe I'm just doing something wrong) Yes, you're right. > I propose #163 to address this issue, which builds on your PR. #163 allows me to create a package whose `guile` executable is ready to be under `wine` out of the box. Nice! Possibly we'l want the libraries to be propagated-inputs for mingw instead of symlinking them manually but we can address that in #163

michaelkaeppler commented 2026年04月10日 09:09:44 +02:00

@janneke wrote in #90 (comment):

Nice! Possibly we'l want the libraries to be propagated-inputs for mingw instead of symlinking them manually but we can address that in #163

I also thought about that, but wouldn't that mean that every bit of the packages, not only the needed DLLs, would be installed into the profile, therefore cluttering it a lot? It would also mean that an uninstalled package could not be run directly from the store, IIUC.

I also wondered why libgc and libunistring are already propagated-inputs, do you know something about that?

@janneke wrote in https://codeberg.org/guile/guile/pulls/90#issuecomment-12937476: > Nice! Possibly we'l want the libraries to be propagated-inputs for mingw instead of symlinking them manually but we can address that in #163 I also thought about that, but wouldn't that mean that every bit of the packages, not only the needed DLLs, would be installed into the profile, therefore cluttering it a lot? It would also mean that an uninstalled package could not be run directly from the store, IIUC. I also wondered why `libgc` and `libunistring` are already propagated-inputs, do you know something about that?

michaelkaeppler commented 2026年04月11日 23:41:33 +02:00

Are there objections against merging this?
AFAICT, the patch improves the development and testing situation on the x86_64-w64-mingw32 target
and is restricted to it, so it's very unlikely to break things, IMHO.

Are there objections against merging this? AFAICT, the patch improves the development and testing situation on the `x86_64-w64-mingw32` target and is restricted to it, so it's very unlikely to break things, IMHO.

old commented 2026年06月06日 16:19:01 +02:00

I will review this later this evening and merge it

I will review this later this evening and merge it