In May, John Lam (behind Ruby CLR) put me in touch with the Visual Studio team at Microsoft. They were very concerned that the Ruby interpreter was being built on an obsolescent version of the Visual C++ compiler and were wondering what might be able to be done toward getting Ruby built with Visual Studio 2005. On June 26th, I had a conference call with the team and pointed out issues that I had experienced in the past and where I had stumbled currently. I posted a message (
[ruby-talk:199211]) immediately after seeking specific issues to deal with. So here I am, seeking even more than I’ve gotten already.
They asked for as much information as I can gather on this matter. If you have had problems trying to get Ruby or an extension compiled or running on Windows for any reason, but especially because of Microsoft runtime DLL differences, please provide me as much information as possible so that I can pass it on to the VS team at Microsoft.
I’ve already heard complaints about compile-time compiler options and general annoyance at incompatible ABIs between runtimes, and suggestions on how to reduce the dependency of an extension on any given Windows runtime. It doesn’t solve the fundamental issue of memory management (and general resource management) between an extension, Ruby, and the library that the extension is written for possibly being tied to three different runtimes.
For what it’s worth, I have Ruby itself compiled with VS 2005, although some of the extensions are not being built automatically, from what I can tell. That may be a build script problem. However, based on earlier reports of runtime version incompatibilities, it was looking like I was going to have to recompile a *lot* of code. The discussion today suggested that as long as function accesses are used and not variable accesses, things will be okay (e.g., GetError() in Windows, not errno). The problem, as I pointed out to them, is that *most* Unix developers only ever have to worry about a single C runtime being on their system and therefore don’t need to worry about errno being in a different runtime DLL. Ideally, they would be able to give us an external way of getting at the errno from a specific
runtime that may not be “our” runtime (e.g., the runtime with which we were linked).
So, I ask you: What other problems have people had and what can you provide me as evidence? Also, can I give them your name and email for direct contact? I will be headed to Europe soon and won’t be able to respond quickly.
[Update 2006.09.11: I am closing this entry’s comments as several spam attempts have been made. If you have issues to report, please report them on comp.lang.ruby and I’ll see them on ruby-talk.]
I heard that the ruby distributed with the one-click-installer will be built on mingw after 1.8.5, and it seems that extension authors that write for *nix will find it easier to get their extension compiling correctly in windows with mingw, which would give a good standard i guess.
It'll give a poor standard on Windows. It'll work, but it's not the most up-to-date compiler and it's using a different runtime entirely. Curt's plans -- which aren't a rumour -- are primarily based around the current mess, which can't be resolved without additional information.
Strictly speaking, one should try to build any platform using a platform's native compiler. It's more likely to be well-tuned for performance on the platform.
I'm not sure that mingw is ready for 64-bit yet. Mingw will probably lag behind Vista support as well, meaning that no one can really take advantage of new features under a mingw build. I would much rather see Ruby built with the native compiler but *compatible* with a mingw-built extension. But mingw isn't the final answer.
Yes, Austin is correct. The first choice would be to build with the MS compilers (espcially now that a free version is available).
Austin, please keep me posted on this.
I tried to compile 1.8.4 using mingw and while simple scripts would run, webrick would not. I was just returned to the command prompt.
I tried VS 2005 Express but could not get it to compile 1.8.4 after much effort, so resorted to buying VC++ 6.0 of ebay - this only compiles from the command line, not using the IDE so no debugging.
Note that you *can* compile Ruby with the command-line tools with Visual Studio 2005 Express (C++) if you grab a stable snapshot after mid-January.
It just won't do you much good because of extension compile time issues.
I don't understand why people in the Ruby community should spend effort attempting to get a non-open-source compiler working. mingw seems like a reasonable choice here.
Binding the future of Ruby on any platform to a closed-source proprietary build environment seems like an obvious wrong answer to me. Far better to get the Visual Studio team working on bringing mingw up to speed than to get Ruby compiled with VS tools if there are Windows/mingw issues.
So I hope a month late isn't too late, but here are some issues anyway:
Compiling ruby extensions:
MSVCR80.dll: Compiling an extension under VC8 and then loading the extension results in the problem of ruby not being able to load the DLL correctly, or some missing functions in the dll.
I hear VS2003 works fine though.
VC8 uses an old C standard, so C code has to be tweaked a bit.
Specific problem:
Including ruby.h after fmod.h (www.fmod.org) resulted in several link errors saying that some core win32 api functions were already defined (memorybarrier, zeromemory something and bitsetandcomplement)
oh, include ruby.h before fmod.h fixed the link problems.