Revolution Systems Blog

Installing Apache2::Request on a 64-bit system

I usually shy away from using 64-bit systems unless there is a clear need for it.  But with more and more hosting companies installing 64-but Linux distrobutions by default I sometimes have to suffer through.

Today I ran into a very small bug in installing Apache2::Request modules via the CPAN shell.  This simply installs the default libapreq2 library with the Perl bindings for you. When attempting to start Apache I received this error:

Can't load '/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/APR/Request/Request.so' for module APR::Request: libapreq2.so.2: cannot open shared object file: No such file or directory at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230. at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/APR/Request/Param.pm line 27 Compilation failed in require at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/APR/Request/Param.pm line 27. BEGIN failed--compilation aborted at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/APR/Request/Param.pm line 27. Compilation failed in require at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/Apache2/Request.pm line 2. BEGIN failed--compilation aborted at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/Apache2/Request.pm line 2.

Basically it is saying it can't load libapreq2.so.2.  Digging around in the system I found it had installed them in /usr/lib instead of the proper /usr/lib64.  The actual shared library was compiled for 64-bit, but was just installed in the wrong location.  A quick symlink like this fixes the isuse:

ln -s /usr/lib/libapreq2.so.2 /usr/lib64/libapreq2.so.2

Hope this helps you get over this small issue.

Django Software Foundation

The Django guys have scored another milestone today with the creation of the Django Software Foundation. Being a huge Open Source advocate I love hearing great news like this.  You can read more about the foundation at:

• Announcing the Django Software Foundation
• New Foundation for Django

On an unrelated note, an article I wrote for LinuxPro Magazine last November about using Perlbal was recently put online.  You can read it at The Juggler -- Let the nimble Perlbal webserver keep your traffic in balance .

Building mongrel on Solaris

I keep running into this same situation, so I figured I would write a post for everyone's benefit.  When trying to build recent mongrels or some other gem dependencies such as fastthread on a Solaris system the automatically generated Makefile is all sorts of messed up. 

This testing was done on two different Joyent Accelerators, your milelage may vary on other Solaris installations.

The steps are pretty easy:
1. Attempt to install the gem via the normal 'gem install mongrel'
2. This will fail, but will download the gem for you.
3. Move into your gems directory.  On these sytems that is /opt/csw/lib/ruby/gems/1.8/gems/
4. Move into the particular gem you are building that is causing you trouble. In this case mongrel-1.1.3
5. Move into the ext/ directory and the subdirectory that can't be built.  You'll see it in the error messages from step 1.
6. Edit the generated Makefile as such:

    Make sure CC is pointing to your C compiler, I had to edit this to reference gcc rather than cc.
    Make sure LD is pointing to a real ld tool.  On this system that meant I changed ld -G to gld -G
    Edit CFLAGS to be CFLAGS= -03 -I/path/to/libs Essentially you just need to remove the -KPIC and all     -x es from the generated file.

7. Run make install
8. Copy the gemspec file to /opt/csw/lib/ruby/gems/1.8/specifications so it will be registered with the gem tools.

Hope this helps.

Some interesting links

Hope all of my readers have recovered from the holiday season.  Here are a couple links I've come across recently, but neglected to write about during the holidays.

Zed Shaw, author of mongrel which is used by many Ruby on Rails applications, posted an interesting rant about the state of Rails development and the personalities of some of the major players. 

I've never been a huge fan of Rails because I've never been shown a compelling reason to switch away from the more mature Perl equivalents.  Lately I've been working with mongrel and Rails apps more and more as many of my clients have switched to that as their platform of choice.  The more I work with it the less fond of it I am, it really is just immature compared to other platforms out there.  Toward the end he mentions the Rails creator himself has an application that had to be restarted 400 times per day... with some fixes it only has to be restarted 10 times a day.  400 is just insane, but 10 is still very troubling.  If the creator can't make things run better than that it really doesn't speak well for the platform.  Normally I wouldn't link to such a huge rant, but when it comes from a major Rails contributor there has to be at least some truth to it.

My friend Stas Bekman has created a new site where you can make it known how you want a better version of something.  It's called i-want-a-better.com.  I think it's a great way for people to vent their frustrations with products, but I think the really winning idea is that entrepreneurs can peruse the site for new products and untaped markets. Hop on the site and let us all know what's frustrating you!

 

Safely making changes to remote systems

I stumbled across this post about a great technique for safely making configuration changes to remote systems.  Everyone has done it before, the "Oops I just shutdown sshd" or turned off the wrong network interface.  Ask Bjørn Hansen shows you how you can use atd to give yourself a safety net when doing these types of operations.