You might have noticed that I started moving (renaming) Ruby packages, both with old and new ebuilds, to drop the ruby- prefix from packages such as ruby-mmap, ruby-bz2 and ruby-fcgi. My reason to proceed in this way is not only to avoid duplication, but to have an extra safety that the name of the ebuild is going to correspond (minus casing, most of the time) with the gem’s name. This gets even more important since the fakegem eclass will default to use the ${PN} variable to do its magic tricks for fakegem handling.
But the tipping point for this set of changes (which aren’t really easy, nor transparent) has been the dev-ruby/ruby-fcgi package we used to ship. Even Alex assumed that the gem it referred to was ruby-fcgi that exists, but in truth it has always simply been fcgi which is a different gem. To avoid these possible collisions in the future, the rule is going to be “use the original naming, don’t add prefixes!”. Obviously there are and there will be exceptions, such as the jruby-debug-base package that installs a gem named ruby-debug-base (this is to sidestep the dependency tracking in the original ruby-debug to let it load the JRuby specific code instead).
This post is not, though, about the naming scheme, but rather should give you an idea why we still haven’t unleashed Ruby 1.9 not even as a secondary Ruby implementation (while JRuby is). You can easily read around the net that “$package now supports Ruby 1.9”… sometimes it’s true, sometimes it definitely is not. For instance when they say that Rails 2.3.5 supports Ruby 1.9 officially, they fail to tell you that builder (which is bundled by activesupport — and slightly patched, but we’re going to count the patched version anyway) looks pretty broken on Ruby 1.9, assuming its testsuite works as intended, which is what appears to me. And the rest of the code does not seem to be much better: tmail fails its tests, among many.
In the case of fcgi (which used to be mandatory dependency of rails 2.3.5 in Gentoo, although I’ve dropped it in the ruby-ng port, as it’s not really that needed, and the gem itself does not depend on it), the original code (version 0.8.7) does not work on Ruby 1.9. And we knew that, Alex added a 1.9 compatibility patch in Gentoo before: it built, and we shipped it, but… was it tested? Nope, since the old eclasses had no support for testing. Actually, I hit this problem when, a few months ago, I added a further safety check for Ruby 1.9: the linked extensions are built with --no-undefined so that eventual undefined symbols won’t cause Ruby to abort at runtime (which happened to me before). Indeed, even though the extension “compiled”, it left the undefined symbols, so it could never be loaded properly at runtime, because the function it used are Ruby 1.8-only and not defined in 1.9 at all. At the end – both on the in-tree ebuild, and in the testing overlay for the new eclasses – I ended up disabling the native extension for anything that is not Ruby 1.8 (there is a pure ruby, slower implementation that works even on Ruby 1.9 and JRuby).
But that’s for the “old” fcgi gem, let’s look at the description from the new one (emphasis mine; grammar quoted):
FastCGI is a language independent, scalable, open extension to CGI that provides high performance without the limitations of server specific APIs. For more information, see http://www.fastcgi.com/. This is the fork of fcgi implementation for ruby but with ruby1.9 – ruby1.9.1 compability
So this should actually have the extension working correctly with Ruby 1.9, you’d say. After all, the previous pure Ruby extension worked fine already, nothing to do there. Okay, so let’s build it (after fixing a three years old bug):
make -j12 -s
fcgi.c: In function ‘fcgi_stream_puts_ary':
fcgi.c:285: warning: implicit declaration of function ‘rb_inspecting_p' [-Wimplicit-function-declaration]
fcgi.c: In function ‘fcgi_stream_puts':
fcgi.c:309: warning: implicit declaration of function ‘rb_protect_inspect' [-Wimplicit-function-declaration]
fcgi.o: In function `fcgi_stream_puts':
/var/tmp/portage/dev-ruby/ruby-fcgi-0.8.9/work/ruby19/ruby-fcgi-0.8.9/ext/fcgi/fcgi.c:309: undefined reference to `rb_protect_inspect'
fcgi.o: In function `fcgi_stream_puts_ary':
/var/tmp/portage/dev-ruby/ruby-fcgi-0.8.9/work/ruby19/ruby-fcgi-0.8.9/ext/fcgi/fcgi.c:285: undefined reference to `rb_inspecting_p'
/var/tmp/portage/dev-ruby/ruby-fcgi-0.8.9/work/ruby19/ruby-fcgi-0.8.9/ext/fcgi/fcgi.c:285: undefined reference to `rb_inspecting_p'
collect2: ld returned 1 exit status
make: *** [fcgi.so] Error 1
Guess what? that’s the same problem that the old fcgi had with Alex’s patch. It only fails at build time with the Gentoo version of Ruby 1.9 as we’re forcing --no-undefined, on other Ruby 1.9 packaging, you’ll get this to build… and then kill your Ruby process at runtime. So no, this gem is definitely not compatible with Ruby 1.9 even though it is stated so.
Now, there is another fork of the classic fcgi gem, with version 0.8.8, what does change in that? Well the first problem is that the content of the gem has not changed the version at all:
flame@yamato fcgi % egrep '0.8.[78]' . -r
./README:Version 0.8.7
Code language: CSS (css)Is this enough to mutter “boooooring”? Maybe, but to be fair, let’s try building for Ruby 1.9:
flame@yamato fcgi % ruby19 extconf.rb
checking for fcgiapp.h... yes
checking for FCGX_Accept() in -lfcgi... yes
creating Makefile
flame@yamato fcgi % make
x86_64-pc-linux-gnu-gcc -I. -I/usr/include/ruby19-1.9.1/x86_64-linux -I/usr/include/ruby19-1.9.1/ruby/backward -I/usr/include/ruby19-1.9.1 -I. -DHAVE_FCGIAPP_H -fPIC -march=barcelona -O2 -ftracer -pipe -ftree-vectorize -floop-block -g -ggdb -Wstrict-aliasing=2 -Wno-format-zero-length -Wformat=2 -Wno-error -Wno-pointer-sign -fdiagnostics-show-option -fno-strict-aliasing -O2 -g -Wall -Wno-parentheses -fPIC -o fcgi.o -c fcgi.c
fcgi.c: In function ‘fcgi_stream_puts_ary':
fcgi.c:276: warning: implicit declaration of function ‘rb_inspecting_p' [-Wimplicit-function-declaration]
fcgi.c: In function ‘fcgi_stream_puts':
fcgi.c:300: warning: implicit declaration of function ‘rb_protect_inspect' [-Wimplicit-function-declaration]
x86_64-pc-linux-gnu-gcc -shared -o fcgi.so fcgi.o -L. -L/usr/lib64 -Wl,-R/usr/lib64 -L. -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--sort-common -rdynamic -Wl,-export-dynamic -Wl,--no-undefined -Wl,-R -Wl,/usr/lib64 -L/usr/lib64 -lruby19 -lfcgi -lpthread -lrt -ldl -lcrypt -lm -lc
fcgi.o: In function `fcgi_stream_puts':
/home/flame/mytmpfs/fcgi/ext/fcgi/fcgi.c:300: undefined reference to `rb_protect_inspect'
fcgi.o: In function `fcgi_stream_puts_ary':
/home/flame/mytmpfs/fcgi/ext/fcgi/fcgi.c:276: undefined reference to `rb_inspecting_p'
/home/flame/mytmpfs/fcgi/ext/fcgi/fcgi.c:276: undefined reference to `rb_inspecting_p'
collect2: ld returned 1 exit status
make: *** [fcgi.so] Error 1
Okay so we’re back to the same problem, even this version which is supposed to be fixed to work with Ruby 1.9… is simply not, it’s a bundling together of the old code and some patch, the same patch that Alex used, maybe even picked up from Gentoo in the first place. Now, I can’t just reduce from this that all the compatibility with 1.9 is done this way, but it sure should tell you a lot about what “Ruby 1.9-compatible” might mean.
Sigh!