Reputation: 329
I want to insall tiny_tds on Ubuntu 20.04, so I do
apt install freetds-dev
and the install the gem
gem install tiny_tds
Works like a charm on Ubuntu 18.04, but 20.04 fails. the last lines of the output are:
current directory: /home/myuser/.rvm/gems/ruby-2.7.0/gems/tiny_tds-2.1.2/ext/tiny_tds
make "DESTDIR=" install
make: /usr/bin/mkdir: Command not found
make: *** [Makefile:202: .sitearchdir.-.tiny_tds.time] Error 127
make install failed, exit code 2
Any ideas on how to work around this? I have Ubuntu 20.04, RVM with Ruby 2.7 active.
Upvotes: 1
Views: 1989
Reputation: 5243
This problem can be caused by upgrading your base OS, which may change the default paths for different tools such as mkdir
. Normally, most shells follow the PATH
to search for an executable. However, when you're installing gems using Ruby & RVM, there is a lot going on behind the scenes for compiling "native extensions". Traditionally many Unix, Linux & BSD (*nix) C / C++ projects will follow the standard ./configure && make && make install
pattern. The ./configure
script generally detect details about the system at build-time, then auto-generate a Makefile
catered to that particular system. On GNU systems, the autotools
maintainer tools are used to also auto-generate a POSIX compatible ./configure
script, and Makefile.in
template that can be used by ./configure
to generate the final Makefile
.
When gem install
or bundle install
needs to compile a native C / C++ extension for something, it also generates a Makefile
with system-specific details. In this example, it's found that mkdir
utility should be located at /usr/bin/mkdir
.
As part of this process, the mkmkf
gem is automatically generating a Makefile
, usually from an extconf.rb
script with a configuration matching your system, from RbConfig::CONFIG
. However, in this case, the mkdir
utility is actually located at /bin/mkdir
. So, the RbConfig::CONFIG
settings are now incorrect for your system. This probably happened because you upgraded to Ubuntu 20.04, but had old rubies installed to ~/.rvm
already pre-configured for the older OS release.
So, this is caused by having incorrect RbConfig::CONFIG
keys. In this case: MKDIR_P
or MAKEDIRS
.
Sometimes you just need a quick hack to fix a tool's path. This can work in a lot of cases, but sometimes can cause issues when your base OS has changed a lot. In cases like that, use the full clean & reinstall method below.
Find your current rbconfig.rb
file using RVM:
find ~/.rvm/rubies/$(rvm current | cut -d@ -f1) -iname 'rbconfig.rb'
Edit the file and fix the MKDIR_P
and MAKEDIRS
keys on the RbConfig::CONFIG
object:
# Your path may be different. Use the one you found from Step #1
$EDITOR ~/.rvm/rubies/ruby-2.7.1/lib/ruby/2.7.0/x86_64-linux/rbconfig.rb
# Now change the lines:
CONFIG["MAKEDIRS"] = "/usr/bin/mkdir -p"
CONFIG["MKDIR_P"] = "/usr/bin/mkdir -p"
# To:
CONFIG["MAKEDIRS"] = "/bin/mkdir -p"
CONFIG["MKDIR_P"] = "/bin/mkdir -p"
Save the file and retry your gem install
command:
gem install tiny_tds
Generally, editing rbconfig.rb
by hand is not recommended because it's generated from the ./configure
script when compiling Ruby itself. There are a lot of RbConfig::CONFIG
keys & values which means there is a lot that could go wrong. For example: If some core system libraries changed places or versions, you'll probably run into problems related to linking against those old base OS libraries. In cases like this, it's best to just reinstall a ruby compiled against your base OS.
Re-install your ruby
# -j $(nproc) is optional... but can speed up your build by using multiple CPU cores.
# If you don't have the 'nproc' tool, just pass the number of CPU cores to `-j`
rvm reinstall --disable-binary $(rvm current | cut -d@ -f1) -j $(nproc)
Retry your gem install
command:
gem install tiny_tds
Upvotes: 3
Reputation: 138
I had a similar problem installing gems on Ubuntu 20.04. with RVM und Ruby 2.7.
As stated, the make process could not find the mkdir
command.
$ which mkdir
/bin/mkdir
Since the process is searching for the command in /usr/bin/mkdir
it cannot be found. I could fix this by creating a symbolic link to the correct path:
sudo ln -s /bin/mkdir /usr/bin/mkdir
Upvotes: 10