Re: Guile with win32 cross compiling

[Andy Wingo]

Hi Volker,

On Sat 21 May 2011 00:19, Volker Grabsch <address@hidden> writes:

> Jan Nieuwenhuizen schrieb:
>>     https://github.com/janneke/gub/blob/guile-2.0/gub/specs/guile.py
>>     https://github.com/janneke/gub/tree/guile-2.0/patches
>
> As far as I can see, you have patched libgc to support pthreads
> under MinGW. You forward-ported those patches from libgc-6.8 to 7.2,
> so I'm wondering why those patches didn't make it into upstream
> (i.e. the official libgc project) during that time. Are there any
> issues with those patches that I should know about?
>
> Also, have you actually offered these patches to upstream? If so,
> what's the URL to their bug tracker, or mailing list archive, where
> this issue has been discussed? I haven't been able to find any such
> information in neither the *.py file not the patch files.

FWIW there should be a new libgc tarball out, if not now, then within
the next few days.

The libgc list is address@hidden  I have found the libgc
maintainers to be very responsive.  If there is a problem with mingw and
threads that is fixed by Jan's patches, I'm sure they would be happy to
have them.  Who will submit them there, Jan or Volker?

> 2) The struct_timespec / ipv6 / etc. issues
>
> It seems that you solve those issues using an even uglier hack
> than I did. I'm wondering why it is necessary to manipulate the
> config.cache, as providing those variables as ./configure paramters
> worked quite well for me.
>
> Moreover, is this a sensible thing to do anyway? Shouldn't we try
> to fix the configure.ac to make it more portable and to make it
> properly detect those MinGW things in the first place?

I have not looked at the patch, and am away from the internet at the
moment, but patching config.cache isn't really a bad thing, AFAIU.

Here's the deal.  Configure scripts attempt to figure out what features
your system supports by doing configure-time feature checks (not
platform checks).  But if you are cross-compiling, sometimes it doesn't
have all of the information that it needs.  In that case, the configure
script will make an assumption.  When that assumption does not hold for
you, you need to midify the assumption that it's going to make, by
setting a cache variable.

You can set a cache variable on the ./configure command line, or set it
in a config.cache or config.site file.  It doesn't matter which.  In
fact config.site is often the nicest solution, as you don't have to muck
up all of your ./configure invocations.

Hope this helps,

Andy
-- 
http://wingolog.org/