Re: [Spam] Re: What's the status of compiler/compiling on windows?

On Dec 12, 2007 4:05 PM, Joe Swatosh <[e-mail]> wrote:
>
> I apologize for the late reply/threadjack, but I am curious about the
> nature of the
> problem on windows with extensions compiled with a different compiler than
> Ruby itself.
>

This was discussed in other thread in ruby-talk, but just to summarize:

1) memory allocated by one runtime cannot be free'ed by another, that
ends in segmentation faults.

Example Scenario:

A) Ruby build with VC6 (the current official build).
B) Extension manually hacked to build with VC8 (this requires
rbconfig.rb modifications).

A is linked to MSVCRT.DLL, and B is linked to MSVCR80.DLL
You allloc something in you side that get free'ed by your extension
(calling C free()), that ends with a crash.

This is no a theorical scenario, happened to me when compiling libfcgi
and ruby-fcgi extension.

Another Scenario:

A) Ruby build with VC8 (your private build)
B) A pre-compiled extension created with VC6, like mongrel,
sqlite3-ruby, mysql, etc.

A is linked to MSVCR80.DLL and provides msvcr80-libruby.dll
B is linked to MSVCRT.DLL and link against msvcrt-libruby.dll

This is a more complex problem: the extension will not work, plain
simple, it will yell at you (msgbox) telling that there is a missing
dependency to get it working.

*Also*, it will have the cross-runtime alloc/free issues listed in the
previous scenario.

> Is the primary issue that Ruby objects created by the extension are created
> in one heap then the interpreter attempts to destroy them in another heap (or
> visa-versa)?  If that is the case, there are some ideas we might be able to
> borrow from the boost::shared_ptr<> implementation that could alleviate this
> problem.

Yes. extensions will malloc on the linked CRT heap, and ruby GC will
try to free'ed it from their CRT heap... and vice-versa

The thing is Ruby will realy *love* some distutils compilation helper
like python has.

Anyway, the MinGW guys just commited a few changes that will allow you
target specific MSVCRT versions with the same compiler, removing the
pain to create extensions with gcc for ruby build with VC6/8/9.

Also, there is a optional mingw component that let you choose the
target CRT before the compile process, instead to link it with ld...

Regarding boost::shared_ptr I cannot comment, mostly since it seems
they use that practice to track reference counting, and that will
require some changes to how ruby works with it, and also extensions.

But please, correct me if I'm wrong or not so clever :-D

Regards,

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams