Re: MinGW build fixes

[Neil Jerram <neil@ossau.uklinux.net>]

ludo@gnu.org (Ludovic Courtès) writes:

>>  SCM_API struct scm_t_cell_type_statistics scm_i_master_freelist;
>> +SCM_API struct scm_t_cell_type_statistics *scm_i_master_freelist_ptr;
>>  SCM_API struct scm_t_cell_type_statistics scm_i_master_freelist2;
>> +SCM_API struct scm_t_cell_type_statistics *scm_i_master_freelist2_ptr;
>
> I don't understand why this fixes anything, since the `_ptr' variables
> are declared as `SCM_API' just like the non-`_ptr' variables.

Indeed.  My guess is that it's because the DLL import/export mechanism
works for atomic data - i.e. chars, ints, pointers etc - but not for
structs.  Or at least, not in the same way - it could be that some
extra magic incantation is needed somewhere.

(For example, there's no problem with scm_cells_allocated, which is
also referenced by the inline scm_cell code.)

I haven't managed to find a reference for this, though.  Also this
restriction could be one imposed by MSVC/Windows, or it could be a
restriction in MinGW's emulation of that.

I guess the thing to do would be to email the MinGW people, so I'll do
that.

> Also, it adds an indirection, which may impact performance.

Yes.  So I guess I should make these diffs #ifdef __MINGW32__.

> Other than that, I think this is good news!

Me too.  On the one hand Windows isn't a free platform, so it can't be
our prime concern.  On the other, I think it's good for us to grow the
possible audience for Guile as much as possible.

(Guile is already in Cygwin, of course, but it's an older version and
AFAIK the build was not straightforward.  So these fixes are about
making Windows builds work out of the upstream box.)

Regards,
        Neil