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

On 7/19/06, Charlie Savage <[e-mail]> wrote:
>
> > 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 :)


Oops... sorry!

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


The 1.8.2  version of the one-click installer was built with VC++7.1 (aka
VS2003). This is where the ERRNO problem first surfaced because most of the
third party extensions built by others used VC++6 or MinGW.

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.


This isn't where you would see the errors. Its when you build Ruby using
VC++ 2005 and then try to load an extension that was built with any other
compiler.

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


This is the whole point of this thread. It appears that the only safe thing
is that the Ruby runtime and all extensions that its uses (both those
included with the one-click installer and those provided by third parties)
need to be using the same compiler and that compiler needs to be freely
available.

I have two choices VS2005 Express and MinGW. What I really want to know (as
succinctly as possible) is what the pros and cons are for each path.

Curt

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