Bundler 1.0 Will Not Install Compiled Gems in UNIX When `bundle install` is Run in Windows #646

charleseff opened this Issue Sep 2, 2010 · 37 comments


None yet

I am running Rails 3.0 with Bundler 1.0. I am also developing on Windows XP and deploying to a Linux machine. My current Windows setup is using MinGW though msysgit.

In my Gemfile I am requiring Nokogiri as follows:

source 'http://rubygems.org'
gem 'nokogiri'

When I run bundle install for my project under Windows, Bundler will generate a Gemfile.lock with the following for Nokogiri:

nokogiri (
nokogiri (

However, Gemfile.lock does not list the UNIX version nokogiri ( I then checkin my Gemfile.lock into git and deploy a release to our Linux server. As part of our Cap script, the server runs bundle install --deployment. Upon doing so, there are four problems.

  1. Bundler will not install the Nokogiri gem on the Linux server.
  2. Bundler will list every other gem in its output, except for Nokogiri.
  3. Bundler will say Your bundle is complete!, even though the Nokogiri gem was not installed.
  4. Because Bundler does not exit with an error, Cap will deploy the app without Nokogiri being built, and the app errors out when a user tries a page that uses Nokogiri.

I believe this may also affect other compiled gems that have native mingw or mswin builds.


For now, please make sure you run bundle install on a platform that is similar to the one you're deploying to (OSX or Linux for Linux, JRuby for JRuby). It's not ideal, and we'll try to have a workable solution for 1.1.


Thanks! I am having this problem too. It's nice to know that someone figured out WHY this is happening.


Installing Cygwin and running "bundle install" should do as a work-around. You'll need to install gcc, make, libxml, and libxsl for nokogiri on cygwin.

Alternatively, can't we just manually add the "nokogiri (" line in our Gemfile.lock with a text editor?


You could, but you might miss out on dependencies (for instance, nokogiri depends on weakling in Java). I certainly wouldn't want to support Gemfile.lock files people were writing and maintaining by hand :(

Bundler member

raggi's implementation idea: http://gist.github.com/654685


Ugh this is a nightmare, I can't easily develop on OSX and linux at the same time ;/ I have to give my deploy user root privaleges so it can generate the bundle :(

This is a major bug, not a feature ...


Here's a quick solution: just kill the "-x86-mingw32" in your Gemfile.lock before pushing the code.


If you are using cruise, you might want to try this: https://github.com/gouravtiwari/windows_linux_fix_for_bundler


I would like to see this fixed. I am working with Mac OS X while my team is working with Microsoft Windows without internet access. At the moment i need to install the gems in Mac OS X and also start my windows virtual machine in hope that all windows gems will be downloaded.

Something like this would be great:
bundle install --platform=ruby,mingw32,mswin32

Bundler will then run for the definied platforms and downloading the gems.


Similar to #635 though this one is Windows specific.

I added my comments and workaround to the #635 issue.


I have run into this issue as well (with Rails 3, and the bcrypt gem)

Please consider this a vote for this.


+1 for a resolution to this issue


Another +1... would be huge to have this.


For those struggling with this issue, here is a workaround I've seen around.

Update your deploy.rb to include
set :bundle_flags, "--quiet"
This will prevent Capistrano from halting due to lack of gemfile.lock
Next, remove your gemfile.lock from your source control system and add it to the your ignore list/file (depending on your poison.)

This will slow down your deployments as bundle will have to recalculate the dependency tree every time.


Another +1


Another +1 for fixing it... This has not been fixed for 2 years ?


+1 from us too (Linux, Windows, OSX w/jRuby and some dep's have c-extensions)


This is a high priority issue. @hone and I will be working on this soon.


Thanks wycats


how can something like this go undiscovered? has nobody ever tried to deploy from a windows machine?!


It seems to me like this issue is specifically related to bundle install --deployment, but would not happen when running a simple bundle install on the remote server.

Can you confirm this?


I would agree with that. This is how you can run bundle install on the remote server with capistrano instead of using the Windows generated Gemfile.lock file:

#635 (comment)

This has been my workaround for months since I deploy directly from Windows. Not ideal and I'm open to alternatives...including getting this issue fixed.


As far as I understand the issue is simply that the Gemfile.lock will specify a windows gem, then silently fails on linux because it cant install a windows gem. I had to generate the Gemfile.lock on the server which obviously creates several other issues regarding versions of gems... but apparently its not Bundlers point to make things work, its point is to make sure that the same code is run on every machine. If that code is not available on another machine (or OS) then it quietly fails.


another 👍


@wycats: since no one spelled it out, yes this is specific to bundle install --deployment

if RUBY_PLATFORM =~ /win32/
  gem "mysql2", :platform => [:mswin, :mingw]
  gem "mysql2", :platform => :ruby

works in several Gemfiles in use here. (mysql2 is just an example gem) Would this not be an advocated solution?


I have been struggling with the issue for a while as well. Not sure this issue is really related to bundler and needs to be fixed here.

For those of you deploying with capistrano, this quick little workaround in deploy.rb worked well for me so far. (with GNU sed installed on windows)

namespace :deploy do

  desc "Remove mingw32 extensions from Gemfile.lock to re-bundle under LINUX"
    task :rm_mingw32, :except => { :no_release => true }, :role => :app do
    puts "    modifying Gemfile.lock ... removing mingw32 platform ext. before re-bundling on LINUX"
    run "sed 's/-x86-mingw32//' #{release_path}/Gemfile.lock > #{release_path}/Gemfile.tmp && mv #{release_path}/Gemfile.tmp #{release_path}/Gemfile.lock"
    run "sed -n '/PLATFORMS/ a\  ruby' #{release_path}/Gemfile.lock" 


before("bundle:install", "deploy:rm_mingw32")

I 'm have a similar problem but would probably want to open a new issue for it. In Windows XP, isn't 'bundle install' supposed to install all the gems and dependencies from the gemfile? This does not happen for me. If it finds missing gems it just stops and I have to install the ones it's looking for. This is a pain but works. You would think that https://rubygems.org would get tired of me hitting the site so often. As it is the server is quite busy. This is slow and tedious and I would love to find some help with it. Thanks!


Thank you DHB, your solution worked for me.


I encountered this bug using Capistrano deploying from Windows to Linux. My (very sloppy) workaround is to add this line to /config/deploy.rb for Capistrano:

set :bundle_flags, "--no_deployment"

I believe this issue should be tagged "Bug" instead of "Feature". The platforms block is broken when you need it most: deploying from one platform to another. +1 to fixing this.

Bundler member

The platforms block cannot magically create a lock for a platform that does not exist. It's a problem, and it's one I want to fix, but it's not a bug. Bundler has never claimed to magically know which gems you need on linux if you have only ever Bundled on Windows before. :\


Fair enough. Any pointers on how one might implement this?

Bundler member

In broad terms, the place to start is probably adding a check that prints a warning but allows installations if the lock doesn't mention the platform that has already been installed from.


But then maybe highlight this to the people? There is no point if almost every Rails person that develops on Windows struggles with this issue. I can't really believe that this issue has been kept so quiet? Has no one ever deployed from windows? What about an entry in the wiki maybe? There are some workarounds. Please don't misunderstand me, I appreciate your work highly, I use bundler every day!

Bundler member

Moved to bundler-features: bundler/bundler-features#4

@xaviershay xaviershay closed this Aug 10, 2013
@zflat zflat referenced this issue in bikebike/BikeBike Sep 3, 2014

Gemfile.lock between platforms #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment