If you use Windows, you must appreciate that there are several gems which require external libraries in order to be “built” properly.
These external libraries are generally not present on your system and are required to be installed (and referenced) to get them working. This is why the likes of the MYSQL2 and RMagick gems are seen as “difficult” to install.
If you’re using SQLite3, things are slightly different.
This gem has several “builds” which are meant to provide functionality across a number of platforms (Windows included). Whilst this works in earlier versions of Ruby, it doesn’t work for Ruby 2.5.1+ – hence the error you’re seeing…
cannot load such file — sqlite3/sqlite3_native (LoadError)
The error is caused by the installation & attempted usage of the “mingw32” version of the gem. This version of the gem is pre-compiled with the SQLite core files, but has issues when being used with the later versions of Ruby.
The solution is to install the gem for the “ruby” platform (which still works fine in Windows):
gem install sqlite3 –platform=ruby
This will install the “native” version of the gem with all the appropriate files etc – but won’t use any of the platform-specific functionality that comes with the likes of the mingw32 version.
This will work 100% out of the box.
However, there’s another problem. If you use “bundler”, it will often override the native gem installation in favour of a platform-specific one. This means that if you run bundle update / bundle install, it will likely install the sqlite3 gem with mingw32 platform.
In this instance, you need to uninstall *any* references to the latter by using “gem uninstall”. Here’s what typically happens (for us):
- bundle update [installs sqlite3]
- gem uninstall sqlite3 [shows selection]
- remove “mingw32” variant
- rails s [should work 100%]
This will get the system working with the gem.
The big problem is that whenever you use the “mingw32” version of the gem, it will have a set of references/calls which are designed specifically to call particular elements of the gem.
In Ruby 2.5.1+ – for whatever reason – these calls are not entirely used to ensure that the system is able to make the most progress, 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 the likes of Linux or Mac as a development environment – this type of thing could be relatively simply averted. But where’s the fun in doing something that’s easy? Use Windows!