From: James Tucker Date: 2008-03-26T00:29:59+09:00 Subject: Re: Bootstrapping Ruby with MinGW: selfhosted and test sandbox! On 25 Mar 2008, at 13:14, Luis Lavena wrote: > Hey Nobu, > > On 25 mar, 03:41, Nobuyoshi Nakada wrote: >> Hi, >> >> At Tue, 25 Mar 2008 06:04:52 +0900, >> Luis Lavena wrote in [ruby-talk:295564]: >> >>> On Mar 24, 5:54 pm, rogerdpack wrote: >>>> Note that binary gems don't work only because they install their >>>> binary aspect into the wrong directory (and, if you have the newer >>>> versions of rubygems, auto-install a version which doesn't exist so >>>> you'd need to specify you want the win32 gem). Once you install it >>>> you can easily copy the .so's to the right directory and they will >>>> 'probably' work just fine. >> >>> Not that, RubyGems consider each platform by it's own. I snot the >>> same >>> darwin8 to cygwin, so mingw32 shouldn't be considered a compatible >>> match to mswin32. >> >> Darwin and cygwin are completely different systems, but mingw32 >> and mswin32 are for the same system. >> >> Not only mingw, gcc is basically intended to be binary >> interface compatible with the system native development >> environments. So cygwin is the special case in this sense. >> > > I just tried to be dramatic, also exposing that RubyGems will not > consider mingw a compatible platform to mswin32, since it's using > RbConfig::CONFIG['arch'] to determine it's platform. > > I'll like to point htat rubygems 'darwin' is compatible with 'darwin7' > and 'darwin8', but version 7 is not compatible with 8, like happens > with buils with VC6 and VC8/9. > >>> In a overlooked way you could be correct, but that is too simplistic >>> way to look things. When you start seeing errors due exception >>> thrown >>> inside shared object we can find several and big issues. >> >>> Consider that the code generated by VC6 is not the same MinGW >>> generates. It even differs in several places on how it do things. >> >> Binary interface compatible means that they use same calling >> convension, same utility functions, same runtime DLL etc, but >> not generated code are identical. > > You're are correct, but real life prove me wrong. > > Even that MinGW generates msvcrt-ruby18.dll library, I cannot put a > pre-compiled extension build with VC6 to run over the MinGW build, it > just crash. > > (Tried several times during the testing procedure). > > Everything depends on the complexity of things the extensions perform, > but instead of guessing and "hoping" not to crash, I put my statement > on bold, underlined text: extensions are not easily interchangeable > between these two build systems. > > To solve this I'll require a lot of deep tracing inside ruby, and I > still want to fix the redirected IO issues I had with Readline and > still noone replied. As you know Luis, I'm desperately trying to make time to come and help you, sort out some of the code i can donate, etc. Sadly, time is lacking. Anyway, it seems this kind of project would be ideal for the Ruby Mendicant project. I know there are a lot of the long-term rubyists who simply say "Oh we don't care about Windows" or "It's a broken platform" / whatever. The fact is, actually getting a performant stable interpreter on the platform would probably do more for the language than any other single action. Of course OCI download numbers from rubyforge can easily attest to this. > > >> -- >> Nobu Nakada > > Thank you for your reply. > > Regards, > -- > Luis Lavena >