I realize this isn't directly gosu related, but you guys are really smart and rubygems has got me seriously bummed...

I've installed Ruby with the "one-click" installer (1.8 and/or 1.9; same problems with either) and "gem install x" very rarely works (basically only for "ruby-only" gems). Any time a gem has to compile native code, something always breaks. I've installed the MinGW compiler tools (i.e. the "devkit"). I've even got TWO versions of Visual Studio, AND cygwin installed!

For example, I just tried to install mixology (so I can try out Legend of Purple Dot) and it looks like it's trying to use a combination of M$ and gcc tools. It calls "nmake" (which can't be found until I run "vcvars32.bat") but the makefile seems to call gcc. Is that right? Even if it is, that fails too, and I don't know why. As I said, I have two copies of gcc installed.

Another example: ruby-opengl. Running "gem install ruby-opengl" fails (as I've come to expect...) but if I specifically go to rubyforge and manually download and install "ruby-opengl-0.??.?-x86-mswin32.gem", it works fine (after I add GL headers to MinGW). So, why doesn't it automatically get the Win32 version? Is there a way to tell it to do so? I know "gem help install" doesn't say anything about it...

For that matter, why do gems come in specific win32 versions, anyway? Can't a single gem package be made to install on any system? There aren't separate MacOSX and Linux ones, so what's so special about Windows (especially considering they use the same Ruby and GCC)?

If the only answer is to keep downloading gems manually (or install Linux :P ) I can accept that, but I'm hoping someone has a simple fix for making the whole "gems" system work like it's supposed to on my PC.

Thanks for reading.

MacOSX and Linux are POSIX compliant so gems can be built from source on both platforms with little changes to the actual source. Windows is a different beast entirely and has it's own proprietry platform. I would first check which version of rubygems you have installed, I believe with version <= 1.0 you had to supply any extra parameter in order to specify the gem be built for Windows. You can check with "gem -v", I am currently running version 1.3.6.

It may be worth doing an update just to be sure, "gems update --system". Then try again.

The problem is that RubyGems' documentation is traditionally more than vague for non-Ruby gems. For example, lacking any official documentation, I've tagged the binary Gosu gem win32-msvc60 or something like that. That let "gem install gosu" recognize it on Windows, even though I build it with msvc80 (or msvc90?). Now the one-click installer switched to being compiled with mingw instead of msvc60, and this means binary gems need to be tagged as i386-mingw32 or something like that. I don't even know if there are 64bit versions or not. I also don't know if there is any potential danger in cheating around with this tag.

tl;dr, if you want to bypass the mess that is gem platform matching, just install gems like this:

gem install gosu --platform=mswin32

Also, there are special pre-built gems for OS X too, at least some (Gosu!) ;)

hello Runner,

mingw and win32 are different platforms as far as rubygems is concerned.

I have a clean windows system with just mingw and the devkit installed and the mixology gem compiles and installs fine, i suggest you get rid of your other C compilers and stick with mingw since there's probably conflicting definitions of some environment variables causing the problem.

The reason gems typically have a win32 version (as well as the 'normal version') is because that gem is a native extension and gem writers do not trust windows users to have a C compiler handy. The win32 version then is a precompiled windows binary whereas the 'normal version' is source code that is compiled during gem installation (this is usually fine for *nix and macosx users)

I've actually looked at the setup for the ruby-opengl gem and it looks like it SHOULD work so i think it's a gem hosting screwup that's causing the problem.

Hey, thanks for all the great info, guys!

@disciplex: I was aware of the POSIX thing, but I always thought that was what the "devkit" add-on was for. Thanks for the tip about updating rubygems, BTW. I'm now running 1.3.6, too (I forgot to check before updating, but it was obviously older than that).

@jlnr: Actually, now I'm not sure how I installed Ruby... Both the 1.8 and 1.9 I have seem to have been compiled with some version of MSVC (there is an "msvcrt-ruby18.lib" for example). Is that why compiling doesn't work? Do I need a version compiled with mingw to use the devkit to compile extensions?

@banister: I think you're right about environment variables being (at least part of) the problem, but I'll just have to try to fix it so that they all get along, since I can't really get rid of any of the other compilers. I would also prefer not to have to install mingw, if at all possible. Is it really necessary to have the full MinGW AND the "devkit" files? What about MSYS?

I have never heard about a devkit, if any gem requires compiling on Windows I'd call it broken ;)

http://rubyinstaller.org/download.html

The problem was that I was trying to use that devkit with the old, VC6 version of Ruby. When I installed Ruby and the devkit from that site, mixology built without a hitch!

Like you, jlnr, I would also think gems with native win32 versions shouldn't have to be built. I think banister explained it as a bug with the gem host. But, in this case, I'm kind of glad mixology didn't work. The native windows gem on ruby-forge is version 0.1.0, but now that I can compile extensions, I can use the 0.2.0 version! (Now I just need to figure out how to use mixology ;)

Now, I'm off to install gosu, texplay, etc. and start having fun with my new, faster, non-broken Ruby environment! Yay! :D

Sorry for the double-post, but it seems I spoke too soon...

There are still problems building both ruby-opengl and gosu. I forgot about the fact that the OpenGL lib is called "libGL" on *nix and "libopengl32" on Windows... Without changes to the gem itself, I see no way to resolve this, so I'll still be forced to manually download the win32 gems until they fix whatever is broken there.

Oh, well... At least I only have to do it once/not very often.

you only need the devkit files iirc, it includes a copy of mingw bundled with it. You don't need msys either. Luis Lavena (the guy behind rubyinstaller and devkit) is awesome and his tools are really pick up and play, i was very impressed with rubyinstaller and devkit, it all worked exactly as advertised for me with no hiccups at all.

regarding mixology the only diff. b/w 0.1.0 and 0.2.0 is that 0.2.0 is 1.9.1 compatible. It's a pity they didn't update the windows binary when i upgraded the source. If you need help using mixology just send me a msg.

Well, I got it working pretty well, now. I got some handy info from Luis himself on the RubyInstaller Google group. He pointed out that the latest version of ruby-opengl doesn't have a win32 gem available in the rubygems.org repository. There's one in the RubyForge project downloads, though. So, I installed the 0.60.0 version by specifying the version number and the full platform specification. That allowed it to install, and gosu, texplay, and DevIL all fell into line after it, so now I'm all set up.

I manually copied the contents of the 0.60.1 gem from RubyForge over the 0.60.0 install in my gems folder, and it hasn't broken anything yet, so I'll try that until they update the repo (which I've mailed them about).

I still want to try to set gem up so I don't have to supply the platform each time, but it'll do for now. I'm wondering if the "update" functionality might be smart enough to take it from here without the hand-holding (assuming the win32 gems are there for it to find) but I'll just have to wait and see...

Thanks again, folks!