Hi Volker, On Sat 21 May 2011 00:19, Volker Grabsch <v...@notjusthosting.com> 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 g...@linux.hpl.hp.com. 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/
