How to Load Correct Version of Dynamic Libraries and Gems (Libxml, Nokogiri) Within a Custom Rails Engine Gem

How to load correct version of dynamic libraries and gems (libxml, Nokogiri) within a custom Rails engine gem?

Put you Rails Engine gem in the top of the app's Gemfile. Then, in the gemspec and Gemfile of the Rails Engine, make sure that you have nokogori before other gems that use libxml (like pg).

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.

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.

Error while trying to generate rspec_helper.rb

Have you tried re-installing Nokogiri?

gem uninstall nokogiri
gem install nokogiri

See if that helps.

nokogiri installation error on MacOS Catalina while bundle install

Try reinstalling everything.

I ended up here after using Ruby on Rails after a few months. Deleted Ruby and cleaned everything up, reinstalled both ruby and rails using rbenv, and updated yarn. Followed the tutorial on goRails and made sure there were no anomalies.

For example, if you installed ruby 3.0.1 but "ruby -v" gives you 2.7.2, there's a problem. If you installed rails 6.1.3 but it shows 6.1.4, that's another problem.

rails aborted! when running `rails new` and `rails s` giving load error for nokogiri and dlopen

The permission error probably means the gem has been installed by user root, doing something like sudo gem install, which means you have to use sudo to remove it too.

Now the nokogiri gem usually relies upon what is called native extensions, i.e. code that has to be compiled for a specific kind of platform.

Here we can see you have nokogiri installed for both x86_64-darwin and arm64-darwin.

Here darwin refers to your operating system (mac OS)

x86_64 is the code named for the 64bit versions of the intel family of processor, something also called amd64 because the first such processor was developed by AMD.

arm64 is another computer architecture, based on ARM which is often use in mobile phones and tablets because of it's lower energy consumption.

arm64-darwin refers to the new Apple Silicon architecture.

Now dlopen is the C api to load a shared-library (.so), and it reports clearly:

 could not use '.../nokogiri-1.11.2-arm64-darwin/l...' because it is not a compatible arch

So you know it's not usable on your system. which means you can probably safely remove it.

Additionaly, you could try using asdf, rbenv, rvm or something similar to manage your ruby versions, which will also keep your gems (depending on how you configure it) in your User's folder so you don't need to worry about sudo.

---

Related Topics