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.

Charlie actually :)

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

Right - this should not work, as Microsoft's documentation says, since
you're setting two different ERRNO global variables, one per linked CRT
(http://msdn2.microsoft.com/en-us/library/ms235460.aspx).

And as I'm sure you know, Microsoft has decided to try and solve DLL
hell by tying the last three versions of VC++ to specific runtime
libraries. So VS.NET uses msvcr70.dll, VS 2003 uses msvcr71.dll and VS
2005 uses msvcr80.dll.  They are not supposed to be mixed together.

For example, Python is built using msvcr71.dll (VS 2003).  That means
you should build Python extensions with VS 2003 and not VC.NET or VS 2005.

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

I haven't built Ruby itself, I've used the versions provided by the one
click installer (both 1.8.2 and 1.8.4).

> 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)?

MingW extensions link against msvcrt.dll.  The version of the one click
installer that I have, a pre-release 1.8.4, appears to be built against
msvcrt.dll according to dependency walker
(http://www.dependencywalker.com/).  So no issues there.  And that would
have also been the case with Ruby 1.8.2.

When I build an extension with VC++ 2005, the extension links against
msvcr80.dll (never had compile/link issues with the Ruby headers and
libraries).  Which means that two CRTs are now in play, msvcrt.dll and
msvcr80.dll (which is also dependent on msvcrt.dll).  At this point you
have to be careful about passing CRT resources between the two CRTs or
else you'll crash the program.

And I'd guess this is where my experience is different - for the
extensions I've built the communication between the extension and Ruby
has been done only via the Ruby C API.  There haven't been any examples,
like you mention above, where Ruby and the extension communicated via a
CRT function such as get_errno and set_errno.

What I don't know the answer to is if you only use the Ruby api for
communication will it always be safe?  Based on the extensions I've
built (ruby-prof, GDAL, GEOS, and the full SWIG ruby test suite) I
haven't had problems.  But that's hardly conclusive proof.  Would be a
good thing to follow up on with Microsoft.

Anyway, having pondered this a bit more....

* Using VC 2005 really means that all extension writers should use VC
2005 also.  If you use MingW, then you have to be careful.

* If you use MingW instead, then you're saying all extension writers
should use MingW.  If they use VC 2005, then you're back in the same boat.

* Worst of all is probably having different binary extensions compiled
with different versions of VC++.

If using just the Ruby API is safe, then in theory these combinations
could be made to work (unless there lots of examples like the one you
mention above).  If its not, then the only solution is everyone uses the
same compiler always and forever for a given Ruby release.  Which the
odds of that happening are probably somewhere around 0 :(

Charlie

P.S. - Great work on the one-click installer, you guys have done a
wonderful job.



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