Compiling guile-2.2.4 for mingw

Compiling guile-2.2.4 for mingw

[Christoph Buck]

Hi!

Currently i try to compile guile-2.2.4 under mingw64 bit. I had some
minor issues in the c source code which i managed to fix by applying
some of the patches from https://github.com/mkeeter/guile-mingw. Namely 

1) 0003-winsock-compat.mingw.patch
2) 0004-start_child.mingw.patch

Now i am at the point where i have a working guile binary and the helper
scripts in the meta directory. But at this point the boostrapping fails
with the following error:

> make[2]: Entering directory '/home/Christoph.Buck/guile-2.2.4/bootstrap'
>   BOOTSTRAP GUILEC ice-9/eval.go
> Backtrace:
> In ice-9/eval.scm:
>     619:8 19 (_ #(#(#<directory (guile-user) 42c5f00>)))
>     155:9 18 (_ _)
> In srfi/srfi-1.scm:
>     640:9 17 (for-each #<procedure 4f5df20 at ice-9/eval.scm:333:13▒> ▒)
> In ice-9/eval.scm:
>     163:9 16 (_ _)
> In ice-9/boot-9.scm:
>     152:2 15 (with-fluid* _ _ _)
> In system/base/target.scm:
>      57:6 14 (with-target _ _)
> In system/base/compile.scm:
>     152:6 13 (compile-file _ #:output-file _ #:from _ #:to _ #:env _ ▒)
>      43:4 12 (call-once _)
> In ice-9/boot-9.scm:
>     841:4 11 (with-throw-handler _ _ _)
> In system/base/compile.scm:
>     59:11 10 (_)
>    155:11  9 (_ #<closed: file 42abaf0>)
>    224:14  8 (read-and-compile _ #:from _ #:to _ #:env _ #:opts _)
>     255:6  7 (compile _ #:from _ #:to _ #:env _ #:opts _)
>    183:32  6 (compile-fold _ _ _ (#:to-file? #t #:warnings (#) # #t ▒))
> In language/cps/compile-bytecode.scm:
>    591:12  5 (emit-bytecode _ #<module (#{ g135}#) 4d77dc0> _)
> In ice-9/eval.scm:
>     163:9  4 (_ #(#(#<directory (system vm assembler) 4f773c0>) # #t))
> In unknown file:
>            3 (_ #<procedure 6675b80 at ice-9/eval.scm:330:13 ()> #<▒> ▒)
> In ice-9/eval.scm:
>     619:8  2 (_ #(#(#(#(#(#(#(#(#(#(#(▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒))
> In unknown file:
>            1 (bytevector-u64-set! #vu8(0 0 0 0 0 0 0 0 0 0 0 0 0 0 ▒) ▒)
> In ice-9/boot-9.scm:
>    752:25  0 (dispatch-exception _ _ _)

> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> In procedure bytevector-u64-set!: Value out of range: -149659645
> make[2]: *** [Makefile:1931: ice-9/eval.go] Error 1
> make[2]: Leaving directory '/home/Christoph.Buck/guile-2.2.4/bootstrap'
> make[1]: *** [Makefile:1857: all-recursive] Error 1
> make[1]: Leaving directory '/home/Christoph.Buck/guile-2.2.4'
> make: *** [Makefile:1743: all] Error 2

I have no idea what might be wrong here or how to fix this problem. Does
anbody have an idea?

Best regards

Christoph Buck

Re: Compiling guile-2.2.4 for mingw

[tomas]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

On Tue, Nov 20, 2018 at 03:31:25PM +0100, Christoph Buck wrote:
> Hi!
> 
> Currently i try to compile guile-2.2.4 under mingw64 bit. I had some
> minor issues in the c source code which i managed to fix by applying
> some of the patches from https://github.com/mkeeter/guile-mingw. Namely 

[...]

> > ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> > In procedure bytevector-u64-set!: Value out of range: -149659645
> > make[2]: *** [Makefile:1931: ice-9/eval.go] Error 1
> > make[2]: Leaving directory '/home/Christoph.Buck/guile-2.2.4/bootstrap'
> > make[1]: *** [Makefile:1857: all-recursive] Error 1
> > make[1]: Leaving directory '/home/Christoph.Buck/guile-2.2.4'
> > make: *** [Makefile:1743: all] Error 2

This looks a bit like an integer wraparound. It could well be that mingw
has a different size for some of its integral types (long int?).

Sorry, this is from a big distance here...

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Compiling guile-2.2.4 for mingw

[Mike Gran]

On Tue, Nov 20, 2018 at 03:31:25PM +0100, Christoph Buck wrote:
> Hi!
> 

> Now i am at the point where i have a working guile binary and the helper
> scripts in the meta directory. But at this point the boostrapping fails
> with the following error:
> 
> > make[2]: Entering directory '/home/Christoph.Buck/guile-2.2.4/bootstrap'
> >   BOOTSTRAP GUILEC ice-9/eval.go
...

> >     619:8  2 (_ #(#(#(#(#(#(#(#(#(#(#(???) ???) ???) ???) ???) ???) ???) ???) ???) ???) ???))
> > In unknown file:
> >            1 (bytevector-u64-set! #vu8(0 0 0 0 0 0 0 0 0 0 0 0 0 0 ???) ???)
> > In ice-9/boot-9.scm:
> >    752:25  0 (dispatch-exception _ _ _)

...

> 
> I have no idea what might be wrong here or how to fix this problem. Does
> anbody have an idea?

Hey Chris,

This is one of two errors.  One problem is that Guile makes assumptions
about the size of long vs the size of a pointer, as do some the
libraries on which Guile depends.  In practice, your Guile needs to be
compiled under MinGW 32-bit where sizeof(void *) == sizeof(long)

There is another error that causes similar problems to the one you are
seeing.  That error is because there is an error in Guile that under
MinGW where it saves temporary files generated by 'mkstemp!' using the
text encoding, so you end up with random carriage returns in your
compiled scheme files.

I do have a working mostly working MinGW Guile on my system.  You can
check out the patches I did on a branch of the repo called
wip-mingw-guile-2.2

git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingw-guile-2.2

At the beginning of the year, I think I submitted the first of these
patches upstream, but, I got around to submitting the rest of them.

Also note that the MinGW threading library (winpthreads) almost works
with garbage collection, but, it isn't 100%, so you may need to only
compile the single-threaded version of Guile.

Good luck,

Mike

Re: Compiling guile-2.2.4 for mingw

[Christoph Buck]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

Mike Gran <spk121@yahoo.com> writes:

> Hey Chris,
>
> This is one of two errors.  One problem is that Guile makes assumptions
> about the size of long vs the size of a pointer, as do some the
> libraries on which Guile depends.  In practice, your Guile needs to be
> compiled under MinGW 32-bit where sizeof(void *) == sizeof(long)

Ok that makes sense.

> There is another error that causes similar problems to the one you are
> seeing.  That error is because there is an error in Guile that under
> MinGW where it saves temporary files generated by 'mkstemp!' using the
> text encoding, so you end up with random carriage returns in your
> compiled scheme files.

I already wondered why my file-pathes were messed up.

> I do have a working mostly working MinGW Guile on my system.  You can
> check out the patches I did on a branch of the repo called
> wip-mingw-guile-2.2
>
> git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingw-guile-2.2
>
> At the beginning of the year, I think I submitted the first of these
> patches upstream, but, I got around to submitting the rest of them.
>
Ok i checked out your branch and it indeed seems to compile under
mingw32. However, I needed to comment out the pollfd struct definition in
lib/poll.in.h to prevent a collusion in the winsock2.h header (see
attached patch file). I guess this can be fixed more adequate somewhere
in the configure scripts? 

> Also note that the MinGW threading library (winpthreads) almost works
> with garbage collection, but, it isn't 100%, so you may need to only
> compile the single-threaded version of Guile.

Ok good to know.

Is there currently no way to get guile running under mingw-64bit? My plan
was to integrate guile in a project of mine which currently only builds
under 64bit.

> Good luck,
>
> Mike
>

Thanks

Christoph


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: poll.in.h.patch --]
[-- Type: text/x-patch, Size: 2377 bytes --]

--- lib/poll.in.h.orig	2018-11-20 17:58:03.317863600 +0100
+++ lib/poll.in.h	2018-11-20 17:58:35.920887000 +0100
@@ -55,12 +55,12 @@
 
 # if !GNULIB_defined_poll_types
 
-struct pollfd
-{
-  int fd;                       /* which file descriptor to poll */
-  short events;                 /* events we are interested in   */
-  short revents;                /* events found on return        */
-};
+/* struct pollfd */
+/* { */
+/*   int fd;                       /\* which file descriptor to poll *\/ */
+/*   short events;                 /\* events we are interested in   *\/ */
+/*   short revents;                /\* events found on return        *\/ */
+/* }; */
 
 typedef unsigned long nfds_t;
 
@@ -75,28 +75,28 @@
 #endif
 
 
-#if @GNULIB_POLL@
-# if @REPLACE_POLL@
-#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
-#   undef poll
-#   define poll rpl_poll
-#  endif
-_GL_FUNCDECL_RPL (poll, int, (struct pollfd *pfd, nfds_t nfd, int timeout));
-_GL_CXXALIAS_RPL (poll, int, (struct pollfd *pfd, nfds_t nfd, int timeout));
-# else
-#  if !@HAVE_POLL@
-_GL_FUNCDECL_SYS (poll, int, (struct pollfd *pfd, nfds_t nfd, int timeout));
-#  endif
-_GL_CXXALIAS_SYS (poll, int, (struct pollfd *pfd, nfds_t nfd, int timeout));
-# endif
-_GL_CXXALIASWARN (poll);
-#elif defined GNULIB_POSIXCHECK
-# undef poll
-# if HAVE_RAW_DECL_POLL
-_GL_WARN_ON_USE (poll, "poll is unportable - "
-                 "use gnulib module poll for portability");
-# endif
-#endif
+/* #if @GNULIB_POLL@ */
+/* # if @REPLACE_POLL@ */
+/* #  if !(defined __cplusplus && defined GNULIB_NAMESPACE) */
+/* #   undef poll */
+/* #   define poll rpl_poll */
+/* #  endif */
+/* _GL_FUNCDECL_RPL (poll, int, (struct pollfd *pfd, nfds_t nfd, int timeout)); */
+/* _GL_CXXALIAS_RPL (poll, int, (struct pollfd *pfd, nfds_t nfd, int timeout)); */
+/* # else */
+/* #  if !@HAVE_POLL@ */
+/* _GL_FUNCDECL_SYS (poll, int, (struct pollfd *pfd, nfds_t nfd, int timeout)); */
+/* #  endif */
+/* _GL_CXXALIAS_SYS (poll, int, (struct pollfd *pfd, nfds_t nfd, int timeout)); */
+/* # endif */
+/* _GL_CXXALIASWARN (poll); */
+/* #elif defined GNULIB_POSIXCHECK */
+/* # undef poll */
+/* # if HAVE_RAW_DECL_POLL */
+/* _GL_WARN_ON_USE (poll, "poll is unportable - " */
+/*                  "use gnulib module poll for portability"); */
+/* # endif */
+/* #endif */
 
 
 #endif /* _@GUARD_PREFIX@_POLL_H */

Re: Compiling guile-2.2.4 for mingw

[Mike Gran]

On Tue, Nov 20, 2018 at 06:16:32PM +0100, Christoph Buck wrote:
> Mike Gran <spk121@yahoo.com> writes:
> 
> > Hey Chris,
> >
> > This is one of two errors.  One problem is that Guile makes assumptions
> > about the size of long vs the size of a pointer, as do some the
> > libraries on which Guile depends.  In practice, your Guile needs to be
> > compiled under MinGW 32-bit where sizeof(void *) == sizeof(long)
> 
> Ok that makes sense.
> 
> > There is another error that causes similar problems to the one you are
> > seeing.  That error is because there is an error in Guile that under
> > MinGW where it saves temporary files generated by 'mkstemp!' using the
> > text encoding, so you end up with random carriage returns in your
> > compiled scheme files.
> 
> I already wondered why my file-pathes were messed up.
> 
> > I do have a working mostly working MinGW Guile on my system.  You can
> > check out the patches I did on a branch of the repo called
> > wip-mingw-guile-2.2
> >
> > git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingw-guile-2.2
> >
> > At the beginning of the year, I think I submitted the first of these
> > patches upstream, but, I got around to submitting the rest of them.
> >
> Ok i checked out your branch and it indeed seems to compile under
> mingw32. However, I needed to comment out the pollfd struct definition in
> lib/poll.in.h to prevent a collusion in the winsock2.h header (see
> attached patch file). I guess this can be fixed more adequate somewhere
> in the configure scripts? 

OK. I don't remember running into that, but, I'll double check when I
get a chance.

> 
> > Also note that the MinGW threading library (winpthreads) almost works
> > with garbage collection, but, it isn't 100%, so you may need to only
> > compile the single-threaded version of Guile.
> 
> Ok good to know.
> 
> Is there currently no way to get guile running under mingw-64bit? My plan
> was to integrate guile in a project of mine which currently only builds
> under 64bit.

Well anything is possible, of course. Here is a list of my recollections,
but it has been a few months since I looked at it.

First, as Eli Z mentions in his email, GMP may need to be fixed to not
make incorrect assumptions about the sizeof(long) and int, etc.

Second, the Guile numbers infrastructure should probably be rejiggered
to keep using 32-bit INum immediate number types even under 64-bit
builds if long == 32-bit, or to always use int64_t instead of int.

Third, there are a few of the Guile Virtual Machine opcodes that need
to disambiguate if it means sizeof(void *) or size of an integer type.

Sorry that is pretty vague.  I can't recall the details.

I think it might be a tricky business overall.

I only fixed that MinGW build enough to enter a game jam with Guile,
so I haven't put too much effort into it, really.  But I came in
10th place, so hooray.

Regards,

Mike Gran

Re: Compiling guile-2.2.4 for mingw

[Mark H Weaver]

Mike Gran <spk121@yahoo.com> writes:

> On Tue, Nov 20, 2018 at 06:16:32PM +0100, Christoph Buck wrote:
>> Is there currently no way to get guile running under mingw-64bit? My plan
>> was to integrate guile in a project of mine which currently only builds
>> under 64bit.
>
> Well anything is possible, of course. Here is a list of my recollections,
> but it has been a few months since I looked at it.
>
> First, as Eli Z mentions in his email, GMP may need to be fixed to not
> make incorrect assumptions about the sizeof(long) and int, etc.

bytevector-u64-{ref,set!} use 'mpz_import' and 'mpz_export', but I don't
see any assumption in that particular code that 'long' is 64-bits.

However, in general, it does seem to be the case that Guile code has
often been written with the assumption that sizeof(long) ==
sizeof(void*).  I fixed several of these instances, but I suspect that
many more remain.  That issue is being tracked here:

  https://bugs.gnu.org/22406

> Second, the Guile numbers infrastructure should probably be rejiggered
> to keep using 32-bit INum immediate number types even under 64-bit
> builds if long == 32-bit, or to always use int64_t instead of int.

No need for rejiggering, because it's already the case.  Guile currently
always uses 'long' as the immediate number type, precisely because
that's the C integer type that GMP's mpz_*_si functions accept.
Specifically, numbers.h contains this:

  typedef long scm_t_inum;
  #define SCM_I_FIXNUM_BIT         (SCM_LONG_BIT - 2)
  #define SCM_MOST_NEGATIVE_FIXNUM (-1L << (SCM_I_FIXNUM_BIT - 1))
  #define SCM_MOST_POSITIVE_FIXNUM (- (SCM_MOST_NEGATIVE_FIXNUM + 1))

> Third, there are a few of the Guile Virtual Machine opcodes that need
> to disambiguate if it means sizeof(void *) or size of an integer type.

I'm not sure I understand.  Can you give a specific example of an opcode
that needs to be disambiguated?

> I think it might be a tricky business overall.
>
> I only fixed that MinGW build enough to enter a game jam with Guile,
> so I haven't put too much effort into it, really.  But I came in
> 10th place, so hooray.

Nice! :)

    Thanks,
      Mark

Re: Compiling guile-2.2.4 for mingw

[Eli Zaretskii]

> From: Christoph Buck <christoph.buck@smartoptics.de>
> Date: Tue, 20 Nov 2018 15:31:25 +0100
> 
> > ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> > In procedure bytevector-u64-set!: Value out of range: -149659645
> > make[2]: *** [Makefile:1931: ice-9/eval.go] Error 1
> > make[2]: Leaving directory '/home/Christoph.Buck/guile-2.2.4/bootstrap'
> > make[1]: *** [Makefile:1857: all-recursive] Error 1
> > make[1]: Leaving directory '/home/Christoph.Buck/guile-2.2.4'
> > make: *** [Makefile:1743: all] Error 2
> 
> I have no idea what might be wrong here or how to fix this problem. Does
> anbody have an idea?

I have a guess: bytevector-u64-set! uses GMP functions to store a
64-bit value, but GMP doesn't yet support that on Windows, because it
thinks it can get away with the 'long' type for that, and 'long' is a
32-bit type on Windows, even in 64-bit builds.

I would suggest first to build a 32-bit Guile against a 32-bit GMP.
If that fails in the same way, then my guess is wrong ;-)

Re: Compiling guile-2.2.4 for mingw

[Jan Nieuwenhuizen]

Christoph Buck writes:

> Currently i try to compile guile-2.2.4 under mingw64 bit.

Oh, interesting!

> I had some minor issues in the c source code which i managed to fix by
> applying some of the patches from
> https://github.com/mkeeter/guile-mingw. Namely
>
> 1) 0003-winsock-compat.mingw.patch
> 2) 0004-start_child.mingw.patch

What is the relation with or status of the wip-mingw-guile branch on
savannah?

    http://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingw-guile-2.2

Does this build on top of that, what would be needed to get
wip-mingw-guile merged?

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com