In Rails 3, I've noticed that every time I invoke the framework, whether from rake
, rails server
, or anything else, I get the following warning:
Nokogiri was built against LibXML version 2.7.7, but has dynamically loaded 2.7.3
Searching on Google yields a few blog posts, all of which suggest rebuilding Nokogiri using explicit lib and include paths. For example:
http://mrflip.github.com/2009-08/nokogiri-hates-libxml2-on-osx.html
But, that didn't solve the problem for me.
Typing nokogiri -v
gives me this:
---
warnings: []
ruby:
engine: mri
version: 1.8.7
platform: i686-darwin10.4.0
libxml:
loaded: 2.7.7
binding: extension
compiled: 2.7.7
nokogiri: 1.4.4
Which seems to suggest that my build went OK, and Nokogiri is loading the correct library versions. So why does Rails complain?
I actually found the answer, and I thought I'd share it here. See my answer below.
The problem is that other libraries are loading the earlier libxml version. I found this by commenting things out in my Gemfile. Specifically, in my case RMagick was loading libxml 2.7.3. (It uses libxml to read SVG files.)
I tried to rebuild RMagick against libxml 2.7.7 like so:
However, RMagick did not seem to care about those flags. It built using 2.7.3 again. (If anyone knows how to build RMagick against a specific libxml version, please do share your knowledge.)
Ultimately, I did find a halfway-decent solution. I decided that if I couldn't resolve the version conflict between these two gems, I'd at least favor Nokogiri, which uses a newer version of libxml. To do that, I figured out which gems in my Gemfile were using Nokogiri and put them first.
So, whereas I once had this:
I now have this:
Now the warning is gone, and RMagick hasn't yet complained. Disclaimer: I don't use SVGs in my apps, so I haven't confirmed that RMagick is fully compatible with libxml 2.7.7.
You could also
require 'nokogiri'
in the first line of your app, before Bundle.require, - then you don't have to figure out what the other dependencies are.