Re: One-Click Installer: MinGW? or VC2005?

Tim, I'm going to top reply since your post was so long. I'm interested in
this, but I have some concerns.

This compiler problem started on the transition from  VC++6 to VC++7 because
they used different runtime DLLs: msvcrt.dll and msvcrt71.dll (i think, this
is from memory). All would be fine except that these dlls contain some
global variables.

The one that I know about is ERRNO. Some Windows api calls set ERRNO and you
have to make a separate call to retrieve the error code. The problem occurs
when the core Ruby is compiled with one version (VC++7 in the case of the
1.8.2 one-click installer) and an extension that was built with the other
version (VC++6). Subtle, hard-to-find bugs occurred when the api call that
set ERRNO was made in one DLL while the call that checked ERRNO happenned in
the other DLL.

This bug really occurred, and caused the Ruby core team to build the
compiler name into the external link symbols. This now prevents you from
mixing compilers between the Ruby core and any loaded extensions.

So, given this new fact of life, how is it that you were able to build Ruby
with VC++2003 and VC++2005 and still load extensions built with MinGW? And
if you did manage to work around the link errors that you get when you try
to load an extension built with a different compiler, how did you manage to
get them to use the same msvcrt*.dll runtime (or were you just unaware of
this problem)?

Curt

On 7/18/06, Charlie Savage <[e-mail]> wrote:

> From my experience using both tool chains on Windows (for the ruby-prof
> extension and SWIG-based extensions for GEOS and GDAL).
>
> * You can build Ruby extensions using MingW that run against Ruby built
> with VC++.  I've done this with Ruby 1.8.2/1.8.4, various MingW releases
> and VC++ 2003 and VC++ 2005.  This used to require changing a small bug
> in ruby.h for Ruby 1.8.2, but that bug has been fixed with 1.8.4.  For
> more info see
> http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2206&group_id=426.
>
> * However, you cannot do this with MingW using VC++ built Ruby.
>
> >   ruby extconf.rb
> >   make
> >   make install
>
> The problem is that extconf is quite limited - it will assume you are
> building your extension with the same compiler that built Ruby (VC++).
> Python avoids this issue because disutils will recognize the compiler
> being used (MingW, VC++) for the extension and provide the correct
> command line parameters.
>
> * If mkrf (http://glu.ttono.us/articles/2006/06/28/mkrf-0-1-0-released)
> can work like Python distutils, then it will become simple to use MingW
> to build extensions that work with VC++
>
> * When compiling with MingW do not link against the ruby *.lib files.
> Instead, just link directly against the DLL (msvcrt-ruby18.dll).  Its
> faster (links much faster) and works better.
>
> * So you need to manually compile your extension or create a makefile to
> do it.  This actually turns out be the way GEOS and GDAL work - they
> have autoconf based build systems so extconf.rb wouldn't fit in anyway.
>
> * The advantage of MingW is that it avoids the unmanaged assemblies that
> VC++8 uses, so its simpler to deal with (this is a good link about
> manage assemblies -
> http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm)
>
> * VC++ has several large advantages on Windows.
>
> First, it lets you debug your extensions while GDB does not support this
> on Windows (or if it does, its never worked for me).
>
> Second, it compiles much faster
>
> Third, there is a lot more help available.
>
> Forth, its quite easy to build Ruby extensions.
>
> * Using MingW on Windows is a huge barrier to entry.  Gettting MingW
> setup, along with msys, is a time consuming process that only
> experienced *Nix developers will understand and be able to do.
>
> * MingW on Windows is not very easy to use.  Its nice to think that you
> can download an open source project, type ./configure, make, make
> install and it will work.  Alas, it doesn't really work that way. There
> are myriad of issues you run into.
>
> First you'll need msys.  Then many projects have prequisites that you'll
> have to download and compile.  In addition, you often times have to
> change the CFLAGS and LDFLAGS to get successful compiles.  Linking is a
> pain and requires hand-holding, and sometime just doesn't work.  Libtool
> is really flakey on Windows.  For some projects, you'll have to need to
> download/build/install the latest version of it.  You also need to get
> autoconf/automake installed.  Many projects require bison - something
> I've never been able to successfully compile on Windows. All in all - it
> literally took me weeks to figure out how to get everything to work
> together. The MingW/msys tool chain is quite complex on Windows, and
> most people won't have the time or desire to put forth the effort to get
> it to work.
>
> My recommendation:
>
> * Use VC++ 2005 and get Microsoft to tell us how to properly use
> unmanaged assemblies so that we can avoid dll hell
>
> * Make sure that mkrf  supports building Ruby extensions
> "out-of-the-box" on Windows using MingW if you have it installed.
>
> I think this would be the best of both worlds - you support both tool
> chains.  VC++ is the default one, but MingW should work fine for
> building extensions.
>
> Hope this helps - I'd be glad to share more of my experiences if its
> helpful.
>
> Charlie
>
>
>
>
>
>