Nokogiri Was Built Against Libxml Version 2.7.7, But Has Dynamically Loaded 2.7.3

WARNING: Nokogiri was built against LibXML version 2.7.3, but has dynamically loaded 2.7.8

I have found some fixes for Lion, but none for Mountain Lion yet. Nonetheless I have tried this and it works:

gem uninstall nokogiri libxml-ruby

brew update
brew uninstall libxml2
brew install libxml2 --with-xml2-config
brew link libxml2

brew install libxslt
brew link libxslt

gem install nokogiri -- --with-xml2-include=/usr/local/Cellar/libxml2/2.8.0/include/libxml2/ --with-xml2-lib=/usr/local/Cellar/libxml2/2.8.0/lib/ --with-xslt-dir=/usr/local/Cellar/libxslt/1.1.26/

Source (for Lion): https://gist.github.com/1349681

WARNING: Nokogiri was built against LibXML version 2.7.7, but has dynamically loaded 2.6.16

In the end I had to install the gem against the specific versions of xml2 and xslt I have installed:

gem install nokogiri -- --with-xml2-include=/usr/local/Cellar/libxml2/2.7.7/include/libxml2 --with-xml2-lib=/usr/local/Cellar/libxml2/2.7.7/lib --with-xslt-dir=/usr/local/Cellar/libxslt/1.1.26
#. scrollbar line, so the code can be seen

The problem was most likely bad library management, switching between package managers without being tidy enough about it.

Nokogiri was built against LibXML version 2.7.7, but has dynamically loaded 2.7.3

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:

gem install --no-rdoc --no-ri rmagick -- --with-xml2-include=/opt/local/include/libxml2 --with-xml2-lib=/opt/local/lib --with-xslt-include=/opt/local/libxslt --with-xslt-lib=/opt/local/lib

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:

gem 'rmagick', :require => 'RMagick'
gem 'sanitize' # Has Nokogiri as dependency

I now have this:

gem 'sanitize' # Has Nokogiri as dependency
gem 'rmagick', :require => 'RMagick'

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.

Explain this error: WARNING: Nokogiri was built against LibXML version 2.7.3, but has dynamically loaded 2.9.0

Nokogiri is an XML parsing library, and is effectively a clever wrapper around LibXML, which is a library for parsing XML which is written in C. Nokogiri includes C extensions to interface its Ruby code to LibXML. When you install the gem, it'll compile against the libxml headers available on the system, but at runtime it'll dynamically link against the libxml shared object available on the system. You get this warning when those versions don't match - for example, if you upgrade libxml2 on your system after you install Nokogiri.

The way you fix this is to specify which version of LibXML Nokogiri should build against. You can set this up in ~/.bundle/config, like:

---
BUNDLE_BUILD__NOKOGIRI: --with-xml2-lib=/opt/libxml/lib--with-xml2-include=/opt/libxml/include/libxml2 --with-xslt-lib=/opt/libxml/lib --with-xslt-include=/opt/libxml/include

This basically just sets compile flags to be passed when building Nokogiri's extensions, which lets you specify the location of the LibXML installation to use. Uninstall Nokogiri and let Bundler reinstall it after putting that config (and the right libxml2 version) in place, and all will work as expected.

Mac user and getting WARNING: Nokogiri was built against LibXML version 2.7.8, but has dynamically loaded 2.7.3

I just spent the better part of the morning working through this warning. This fix is for people using Mac OS Lion. The fix above using

bundle config build.nokogiri --with-xml2-include=/opt/local/include/libxml2 --with-xml2-lib=/opt/local/lib --with-xslt-dir=/opt/local

is for Snow Leopard with libxml2 installed via MacPorts.

With Lion, libxml2 is loaded as part of the bootstrap process. Regardless of which libxml2 Nokogiri is pointing to, the Lion system default library for libxml2 will be used at runtime. Lion uses libxml2.2.7.3 found in /usr (not /usr/local).

As mentioned many other places, one can just ignore the warning. If, like me, the warning drives you crazy, you can do this:

bundle config build.nokogiri --with-xml2-dir=/usr --with-xslt-dir=/opt/local --with-iconv-dir=/opt/local

Interestingly, if you type nokogiri -v at the command line you will get the opposite warning:

WARNING: Nokogiri was built against LibXML version 2.7.3, but has dynamically loaded 2.7.8

This suggests there is more to how libxml2 is being loaded, with Ruby and Rails using the system loaded libxml2 and the command line using libxml2 from the environment path. Anyway, this silences the error for me.

I’ll say it again – this is only for Lion. The previous fix will work for Snow Leopard.

This is the end of the answer. Stop reading here.

---

OK, you didn’t stop reading... well...

NOT RECOMMENDED!!!!!!

You have been warned. You can verify that Mac OSX is loading the libxml2 library in its bootstrap by disabling libxml2 found in /usr/lib. Do something like copying all versions of libxml2*.dylib to libxml2*.dylib.old (on my machine this was libxml2.2.7.3, libxml2.2 and libxml2).

After you have done this, running Nokogiri will not produce any errors. That is because it can’t find the loaded libxml2 and will now follow the environment path, eventually finding libxml2.2.7.8 in /opt/local.

BUT you won’t be able to copy the old libxml files back. This is because the OS needs the libxml2 that was loaded in the bootstrap.

Powering off and powering on again will brick your machine. The login screen will hang and hang and hang. Power off and power on again in single-user mode (hold Command-S while rebooting). You can watch the bootstrap occur. Low and behold, it throws an error that it can’t load libxml2 and then stops working.

Power off and power on again. This time boot into recovery mode (either hold Command-R or hold Option and then select the recovery disk). In recovery mode open the terminal (utilities/terminal). Mount /usr/lib on your HD (try /Volumes/Macintosh\ HD/usr/lib) and copy the libxml2 files back. Reboot and all will be fine.

Explain this error: WARNING: Nokogiri was built against LibXML version 2.7.3, but has dynamically loaded 2.9.0

Nokogiri is an XML parsing library, and is effectively a clever wrapper around LibXML, which is a library for parsing XML which is written in C. Nokogiri includes C extensions to interface its Ruby code to LibXML. When you install the gem, it'll compile against the libxml headers available on the system, but at runtime it'll dynamically link against the libxml shared object available on the system. You get this warning when those versions don't match - for example, if you upgrade libxml2 on your system after you install Nokogiri.

The way you fix this is to specify which version of LibXML Nokogiri should build against. You can set this up in ~/.bundle/config, like:

---
BUNDLE_BUILD__NOKOGIRI: --with-xml2-lib=/opt/libxml/lib--with-xml2-include=/opt/libxml/include/libxml2 --with-xslt-lib=/opt/libxml/lib --with-xslt-include=/opt/libxml/include

This basically just sets compile flags to be passed when building Nokogiri's extensions, which lets you specify the location of the LibXML installation to use. Uninstall Nokogiri and let Bundler reinstall it after putting that config (and the right libxml2 version) in place, and all will work as expected.

Mountain Lion - LibXML & Nokogiri

Putting gem 'nokogiri' above gem 'pg' in my Gemfile fixed this for me.

My Gemfile didn't have nokogiri in it, but it was a dependency that was in Gemfile.lock, so I put it in my Gemfile explicitly.

---

Related Topics