--------------ms090408000402040307050301
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

> 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 <cfis / savagexi.com> 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
>>
>>
>>
>>
>>
>>
> 



--------------ms090408000402040307050301
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJAzCC
AtwwggJFoAMCAQICEFby1ChIT+pmYLkFBWX20TIwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUxMzIyNTQyM1oX
DTA3MDUxMzIyNTQyM1owQzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEgMB4G
CSqGSIb3DQEJARYRY2Zpc0BzYXZhZ2V4aS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDDPyi9Z2s8673fAOxX6/EhWhAo2bb8/BcU7xiV49a9TWExEAufzQuAKvKdRWlm
MKuTwdU/QKgrZ1bCcb3cIznHjFI5AmG4nkqUMzqzgzPDDwbiE6AXYXzdd+efDF1mVUQJF/nm
N26xC576KC3e+T1jK2n4DosnIxqQlTVH02huREgMrnPDR82susVvtKa3BV1xx1Fm1+8qkISp
4Ym8LaBQ72nH879OFLHeH/1oP4FAp7qfZAWtlse8mSajhHN6mAH+wFUOG1yrNsM2mKVVAhIv
ByolY+VTa9RBWXgvOhdmJyQd56fag85/zaUjQfUChiYBmx4IWVbc9TKtcx6btDxrAgMBAAGj
LjAsMBwGA1UdEQQVMBOBEWNmaXNAc2F2YWdleGkuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI
hvcNAQEEBQADgYEAeCTsNZ/SvrF8JPbFBychryTZlDzu415g2JQDaPa9+gBFaMpWvsE/rzNO
2nBhz4nXayb8QQMA5+RjTavo/fEmittd2ZjNYItA7glkw0R01kmf/ZEWehLQrVoQ5bbKycED
giA0ykm/936Gzin+RrXwYc9qp5CGawWFj7ceOqmUv8owggLcMIICRaADAgECAhBW8tQoSE/q
ZmC5BQVl9tEyMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQTAeFw0wNjA1MTMyMjU0MjNaFw0wNzA1MTMyMjU0MjNaMEMxHzAd
BgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIDAeBgkqhkiG9w0BCQEWEWNmaXNAc2F2
YWdleGkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz8ovWdrPOu93wDs
V+vxIVoQKNm2/PwXFO8YlePWvU1hMRALn80LgCrynUVpZjCrk8HVP0CoK2dWwnG93CM5x4xS
OQJhuJ5KlDM6s4Mzww8G4hOgF2F83XfnnwxdZlVECRf55jdusQue+igt3vk9Yytp+A6LJyMa
kJU1R9NobkRIDK5zw0fNrLrFb7SmtwVdccdRZtfvKpCEqeGJvC2gUO9px/O/ThSx3h/9aD+B
QKe6n2QFrZbHvJkmo4RzepgB/sBVDhtcqzbDNpilVQISLwcqJWPlU2vUQVl4LzoXZickHeen
2oPOf82lI0H1AoYmAZseCFlW3PUyrXMem7Q8awIDAQABoy4wLDAcBgNVHREEFTATgRFjZmlz
QHNhdmFnZXhpLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAHgk7DWf0r6x
fCT2xQcnIa8k2ZQ87uNeYNiUA2j2vfoARWjKVr7BP68zTtpwYc+J12sm/EEDAOfkY02r6P3x
JorbXdmYzWCLQO4JZMNEdNZJn/2RFnoS0K1aEOW2ysnBA4IgNMpJv/d+hs4p/ka18GHPaqeQ
hmsFhY+3HjqplL/KMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UE
BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD
VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl
cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ
KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw
MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ
c3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1
BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL
B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ
cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYy
aHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD
VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN
BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82
L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3
94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEBMHYwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBW8tQoSE/qZmC5
BQVl9tEyMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTA2MDcxOTA1NDkxNFowIwYJKoZIhvcNAQkEMRYEFBW6pzL4rTgxApEk6gPD
J70DYADWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2
MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVvLUKEhP
6mZguQUFZfbRMjCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u
YWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVvLUKEhP6mZguQUFZfbRMjANBgkqhkiG9w0BAQEF
AASCAQANS+DeogMnze2lnJGqWbqIC1ll5Ac0wO/TYoN6F86PjO43xHwe38+tR9efjq9JK919
7yTMKtRKILmA1c+Ej1InfUt8K8cKh5/ZnezuvcnsJI2pozer+ex1AYlB1ddMI79nLYbKimOw
NIdM6BJXEIXZtsC59KNuXesHaU7afSFYmkCvMnQ3BqI2vtw+xy9v+L8KfX41QOncMAKLiSdy
Q9oxDWUhk9X2IuMsin1j+ho2UanaY90/Vdn9Rb/zW1FGjp7KfXBLiXbfdhoG5kRhWtVWP6DU
MIJfqnDqPNH+vunJg+2n4ToqZY9qOBbv89xXVGFb1QAVMttHryPhjoYHS3l6AAAAAAAA
--------------ms090408000402040307050301--