Compiling Ruby on Arch
There are a few ways of dealing with Ruby/Rails on arch linux. There is a AUR entry for ruby, for 1.8. The default for pacman is 1.9. For my office, we were stuck with 1.8 for the most part so I decided to install by source (AUR may have been easier, but I don’t know it very well so I didn’t use it right now but may later – I do like being frozen at this version for work purposes though…)
To install it the way I did is fairly simple, all you need to do is:
wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p249.tar.bz2
tar -xjvf ruby-1.8.7-p249.tar.bz2
./configure –prefix=/usr –enable-shared –enable-pthread
make && make install
For the prefix, I know it’s usually customary to keep things in /usr/local. For my purpose, I didn’t do that because I had a lot of gems already installed (as well as rubygems itself) and they were in that location from the arch install that I did for 1.9. If you prefer it in /usr/local, just change the configure prefix option above.
The tricky part that I ran into so much was the –enable-shared and –enable-pthread options. Without those, our rake test task just would randomly die with an error such as:
note: ruby[5998] exited with preempt_count 1
BUG: scheduling while atomic: ruby/5998/0×10000002
Modules linked in: ipv6 vmsync vmmemctl vmblock vmhgfs ext2 mbcache snd_seq_dummy fan snd_seq_oss snd_seq_midi_event snd_seq snd_ens1371 snd_pcm_oss gameport s
nd_rawmidi snd_seq_device snd_ac97_codec ac97_bus snd_pcm snd_mixer_oss parport_pc uhci_hcd pcnet32 snd_timer battery vmxnet ppdev ehci_hcd snd soundcore snd_p
age_alloc mii usbcore container ac shpchp pci_hotplug i2c_piix4 intel_agp lp i2c_core processor button thermal psmouse pcspkr parport serio_raw evdev sg rtc_cm
os rtc_core rtc_lib reiserfs sr_mod cdrom pata_acpi ata_generic sd_mod floppy ata_piix libata mptspi mptscsih mptbase scsi_transport_spi scsi_mod
Pid: 5998, comm: ruby Tainted: G D W 2.6.32-ARCH #1
Call Trace:
[] ? thread_return+0×666/0x7ae
[] ? __cond_resched+0x1d/0×30
[] ? _cond_resched+0x2e/0×40
[] ? unmap_vmas+0x8e1/0xaa0
[] ? vt_console_print+0x7c/0×330
[] ? exit_mmap+0xc6/0x1d0
[] ? mmput+0×32/0xf0
[] ? exit_mm+0xfa/0×140
[] ? do_exit+0×136/0x7c0
[] ? printk+0×40/0×45
[] ? release_console_sem+0x1b0/0×200
[] ? oops_end+0xa3/0xf0
[] ? no_context+0xfa/0×260
[] ? HgfsDirOpen+0×0/0×30 [vmhgfs]
[] ? page_fault+0×25/0×30
[] ? task_rq_lock+0x3a/0xa0
[] ? try_to_wake_up+0×58/0×330
[] ? __mutex_unlock_slowpath+0xa1/0×150
[] ? HgfsDirLlseek+0×98/0xe0 [vmhgfs]
[] ? sys_lseek+0x6e/0×90
[] ? system_call_fastpath+0×16/0x1b
stack segment: 0000 [#10] PREEMPT SMP
…..
The part that convinced me of the issue was the line “scheduling while atomic”, which implied it was trying to spawn off another process of sorts and I went hunting around the AUR repository and found the right compile flags that worked. http://aur.archlinux.org/packages/ruby1.8/ruby1.8/PKGBUILD
Overall I was pretty happy that this fix worked – and I’m very curious if we had only one CPU/core, would this have been an issue? I’m not willing to disable it on my virtual machine to find out though.
