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 <address@hidden> 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