If you’re using Windows, you should appreciate that there are several gems that require external libraries in order to be “built” properly.

These external libraries are usually not present on your system and need to be installed (and referenced) for them to work. This is why the MYSQL2 and RMagick gems are considered “difficult” to install.

If you’re using SQLite3 things are slightly different.

This gem has several “builds” that are intended to provide functionality on various platforms (including Windows). While this works in earlier versions of Ruby, it doesn’t work for Ruby 2.5.1+; hence the error you are seeing…

cannot load such a file — sqlite3/sqlite3_native (LoadError)

The error is caused by installing and attempting to use the “mingw32” version of the gem. This version of the gem is precompiled with the core SQLite files, but has problems when used with later versions of Ruby.

The solution is to install the gem for the “ruby” platform (which still works fine on Windows):

gem install sqlite3 –platform=ruby

This will install the “native” version of the gem with all the appropriate files etc, but will not use any of the platform-specific features that come with the mingw32 version.

This will work 100% out of the box.

However, there is another problem. If you use “bundler” it will often override the native gem installation in favor of a platform-specific one. This means that if you run the update/install package, you will likely install the sqlite3 gem with the mingw32 framework.

In this case, you should uninstall *any* references to the latter using “gem uninstall”. This is what usually happens (for us):

  • package update [installs sqlite3]
  • gem uninstall sqlite3 [shows selection]
  • remove variant “mingw32”
  • s-rails [should work 100%]

This will make the system work with the gem.

The big problem is that whenever you use the “mingw32” version of the gem, you will have a set of references/calls specifically designed to call particular elements of the gem.

In Ruby 2.5.1+, for whatever reason, these calls are not fully used to ensure that the system can progress as much as possible, hence the error you’re seeing. To fix this, you need to be able to essentially “force” your system to only use the “ruby” variant of the gem.

Obviously, if you’re using Linux or Mac as your development environment, these sorts of things could be noticed relatively easily. But where’s the fun in doing something that’s easy? Use Windows!