Ruby/rbenv under FreeBSD

setting up freebsd for ruby development, or: we can bring FreeBSD to Google, but can Google being gcloud services to FreeBSD?

FreeBSD is good. Ruby is good. Ruby development really is so much easier with rbenv.

Bring up a FreeBSD VM Instance

Most serious BDS users will want to tool their own incl custom kernels and disk layout (and there are countless ways to do that), but there is also a decent canned FreeBSD 10.3 image available from the freebsd-org-cloud-dev Google cloud project.

gcloud compute instances create bsd0  --image=freebsd-10-3-release-amd64 --image-project=freebsd-org-cloud-dev
gcloud compute ssh bsd0

You might want to edit your instance to make sure the disk stays around on shutdown if this is what you want.

Fix your shells and logins

Here, you will have to set up a decent regimen of user accounts (wheel and not wheel, you know what I mean :-) including ssh access to augment gcloud ssh, keys, etc.

Deploy standard netsec safeguards. It's not that I believe in security through obscurity, but neither am I going publicly into detail on what they are and what their possible shortcomings might be.

Install stuff

pkg install git curl wget 
pkg install mysql56-client sqlite3
pkg install ImageMagick fftw3 minetest
git clone ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
git clone ~/.rbenv/plugins/ruby-build

Gotcha 1: rbenv assumes bash

However, rbenv wants bash because all the cool (Linux) kids are using bash on account of [something about having to have your terminal shell being an awesome scripting language]. Upshot is: rbenv is not natively happy under csh/tcsh (FreeBSD's native happy shell) and needs some extra love.

David Ljung Madison will help you with that:


I have this at the bottom of my .login:

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:$HOME/bin; export PATH

and this in my .cshrc:

set path = (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin $HOME/bin)

# [...]

eval `rbenvWrap init -`

Gotcha 2: sqlite3 gem does not know where to look for includes and libs

Many Rails development and test environments use SQLite (sqlite3). So, it is likely you will need to install the sqlite3 gem which will fail because it assumes includes and libs are kept in Linux-ish places. This should help:

gem install sqlite3 -- --with-opt-dir=/usr/local


bundle config build.sqlite3 -- --with-opt-dir=/usr/local
bundle install

Killer: Google RPC Support is super-green

At this point (2016-08-04), you will not be able to compile the grpc gem extensions due to general green-ness (lack of support for FreeBSD under Google) which is sad because google cloud holds a lot of potential.

> bundle install
Fetching gem metadata from
Fetching version metadata from
Fetching dependency metadata from
Installing google-api-client 0.8.6
Installing grpc 0.13.1 with native extensions

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /home/zeebar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/grpc-0.13.1/src/ruby/ext/grpc
/home/zeebar/.rbenv/versions/2.3.1/bin/ruby -r ./siteconf20160804-41769-z1axx6.rb extconf.rb
Building internal gRPC into /home/zeebar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/grpc-0.13.1/src/ruby/ext/grpc/libs/opt
make: illegal argument to -j -- must be positive integer!
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:

extconf failed, exit code 1

Gem files will remain installed in /home/zeebar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/grpc-0.13.1 for inspection.
Results logged to /home/zeebar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/extensions/x86_64-freebsd-10/2.3.0-static/grpc-0.13.1/gem_make.out

Basically, the grpc gem has not been ported yet. It does not know that on FreeBSD make is not gmake, nor does it know about the subtle differences between Linux and FreeBSD in socket ioctls. Maybe this will get fixed over the coming months, as there is noise on the gsoc boards to that effect.

For now, this is as far as you are going to get at this point. Too bad. So we can bring FreeBSD to Google, but can Google being gcloud services to FreeBSD?


Stay tuned...