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

And the *reason* it's not a theoretical scenario is that Unix doesn't
have this problem (multiple runtimes) in > 99% of cases. Most Unixes
only have one runtime installed and cannot actually have another
runtime installed. Therefore, there's not multiple heaps involved.
Therefore, it's a common case to have an API that says "this C call
allocates memory; remember to free it when you're done with it." There
should be an library_api_free call for every library (e.g., zlib_free,
openssl_free, etc.) just in case, but it's Not An Issue on Unix.

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

Yay!

-austin
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca