Re: MinGW build fixes

[carlo\.bramix]

Hello!

>> 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.

False.
A DLL can export functions, variables, structures, unions and classes.
After few fixes that I'm preparing to share, guile already compiles and it 
works perfectly in cygwin, which uses DLL too: although  it virtualizes a lot, 
cygwin cannot do miracles, it's always windows based and if you add -mno-cygwin 
it becames identical to mingw.
What we could suspect about it is the implementation of -export-dynamic under 
your mingw: which version are you using?
I'm using the latest maintenance releases of gcc 3.4.5 and binutils 2.18.50 
without troubles.
Actually the troubles with mingw are elsewhere... may I ask how you made it 
working?
Unless it has been committed recently, guile cannot be even compiled well 
because it is missing the support for CreateFileMapping(), plus other fixes 
around the code!
Are you using another posix compatibility layer? But I could not see any change 
in your patch for configure script...
Anyways, I would not corrupt guile because an isolated compiler bug (my 
opinion).

Sincerely,

Carlo Bramini.

---------- Initial Header -----------

>From      : address@hidden
To          : address@hidden
Cc          : address@hidden
Date      : Sat, 27 Jun 2009 10:29:54 +0100
Subject : Re: MinGW build fixes

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