So I finally managed to get what I needed to do go create @grpc ruby gems. However, I had to heavily modify the Dockerfile for rake-compiler-dock, and commit it to the repository. I am not happy about that, and I would love if we could make it so that grpc builds out of the box using rake-compiler-dock. But the changes I've made are extremely grpc-centric, and won't work for you without adaptation. Here's the first big issue I've encountered.

The current Docker image for rake-compiler-dock is using mingw32. The problem with that package is it's pretty much obsolete, superseded by mingw-w64. In fact, grpc can't be used with it. The main reason is that it's using antediluvian headers, from the Windows XP era, and doesn't have features that grpc requires from its public headers API. In other words, if you are trying to compile a piece of C code (the ruby extension in that case) against grpc targeting Windows, you can't do that if your Windows SDK is the old mingw32 environment - we require at least Windows Vista.

I don't know if you have any desire to migrate your environment to mingw-w64, but considering it's already disappearing from Ubuntu, it might be a good idea to upgrade at some point.

Here's a list of problems, issues and various thoughts I had while dealing with mingw-w64, if that can help you with the migration, should you decide to go for it.

• I am not sure what's special about the "_rubenvb" mingw-w64 compilers you're downloading, but maybe they're not so much necessary after that change ? I didn't try touching them, but my gut feeling would be to get rid of these after migrating
• Ruby 1.8 and 1.9 didn't compile using it. I didn't really try poking these, as grpc's ruby implementation requires 2.0.0+ anyway. I just got rid of them. Sorry. Shall you need it, I can be of help if you get stuck on these, just contact me. So right now, grpc's rake-compiler-dock image only contains 2.0.0, 2.1.5, 2.2.2 and 2.3.0.
• Once installed, all versions of Ruby had a definition of gettimeofday in win32.h which collides with mingw's. I pushed them away.
• Once installed, Ruby 2.0.0-p645 has a broken test to check for MINGW64, and enters a control path which doesn't work on the new environment. I pushed it away.
• When linking, the mingw-w64 environment creates a direct dependency on libgcc-XXX.dll, and transitive dependencies to others. I solved that by adding -static on the link options of the grpc extension, which is obviously not really something you should force everyone to. But pushing away the flurry of dlls directly into the image might be a good alternative.
• Even when using -static, it still wanted a dependency on libwinpthread.dll. I pushed it away by mangling the docker image directly. Which also shows what I was talking about in my previous point.
• When using -static, obviously, it's using the static version of the ruby runtime dll. In all cases, this is a big no-no, so my workaround might still be useful in the general case when people would shoot themselves in the foot using -static.

That's about it for the mingw-w64 issue :)