[ruby-core:22815] Re: Moving ruby 1.9.1 forward on windows

Hi Roger,

> I suppose you can link against a newer version if desired [1], though
> it's true that the project goes stagnant quite a bit.

If you want to use an unofficial version of gcc 4.x for mingw, then I'd 
go here:

http://tdragon.net/recentgcc/

> I suppose my only concerns with the change are
> 1) are there subtle errors, like you do an ALLOC_N and then the
> library frees it, so you can't control it, resulting in a binary
> incompatibility?

If there are a segmentation fault will occur - so its not subtle.

> 2) Apparently you cannot use structures across different runtimes is
> that right [2]?  I suppose that's not a problem?

No, that is generally not true. VC and Mingw create compatible C binary 
interfaces with one exception that I know of explained here (and there 
is a patch to fix gcc):

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
http://www.angelcode.com/dev/callconv/callconv.html

The only time I have run into this is when creating a Ruby extension 
using VC2008 that called into the proj4 library built with MingW (so it 
really didn't have anything to do with Ruby).  I don't know of any 
examples where this is an issue with the Ruby's C api.

  > Binaries would need to be built [re-built] using VC2008 or mingw cross
> compile linked to that dll, is that right?  I think that would bring
> some sanity to the windows environment as currently it's pretty
> fragmented.

Yes, it is possible to go try and go down the path that there is one 
"blessed" compiler on Windows.  But the point of my proposal was to 
avoid that, giving developers the choice to use whatever compiler they want.

> 2) It allows mingw built binaries to interop with VC ones--binaries
> are much faster if built by gcc [1 #5].

That's an invalid comparison for a couple of reasons.  First you would 
compare VC2008 versus gcc 4.3.  Except you can't, because gcc 4.x is not 
officially released for windows so you're stuck with gcc 3.4.5.

> Do the core folks favor VC2008 or any compiler at all?  It appears
> that as long as you link to the same DLL the two are compatible.

I favor not favoring a compiler.

Now, you do bring up an interesting point, which is instead of favoring 
a compiler favor a runtime library (msvcr90 being the obvious choice). 
  In other words, VC2008 will always link against that one and you can 
mingw to link against it also.  The downside is that you exclude VC2003 
or the upcoming VC2010.

My vote is still to try not choosing a compiler.  I certainly think its 
worth a try.  If it doesn't work, we change tactics.

> Another option would be to release a mingw only OCI linked against
> msvcr90.dll, then instruct extension developers on how to release
> binaries that "pretend" to be mingw though they're only "mingw
> compatible."

There is no pretending here.  Those would be mingw binaries linked 
against msvcr90.dll.  That is supported.  I have no idea if it works 
cross-compiling though.

> Or perhaps rubygems could be patched to recognize compatible binaries.

Not sure what you mean.  My goal is that an extension developer only has 
  to release 1 binary for windows per ruby version.

Charlie