WARNING: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.6.26 (centos 6)

[Brian Henderson]

hi,

I'm trying to follow the suggestion from 

https://github.com/sparklemotion/nokogiri/issues/296

for reporting this issue.

Here is my output from nokogiri -v

WARNING: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.6.26

# Nokogiri (1.6.0)

    ---

    warnings:

    - Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.6.26

    nokogiri: 1.6.0

    ruby:

      version: 2.0.0

      platform: x86_64-linux

      description: ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux]

      engine: ruby

    libxml:

      binding: extension

      source: packaged

      libxml2_path: /usr/local/nextgen/shield/releases/20131010175816/vendor/bundle/ruby/2.0.0/gems/nokogiri-1.6.0/ports/x86_64-redhat-linux/libxml2/2.8.0

      libxslt_path: /usr/local/nextgen/shield/releases/20131010175816/vendor/bundle/ruby/2.0.0/gems/nokogiri-1.6.0/ports/x86_64-redhat-linux/libxslt/1.1.26

      compiled: 2.8.0

      loaded: 2.6.26

the actual error I'm getting is

relocation error: /usr/local/nextgen/shield/releases/20131010175816/vendor/bundle/ruby/2.0.0/gems/nokogiri-1.6.0/lib/nokogiri/nokogiri.so: symbol xmlFirstElementChild, version LIBXML2_2.7.3 not defined in file libxml2.so.2 with link time reference

any help you can offer is appreciated.

thanks,

[Stephen Lloyd]

Yes, same question here: WARNING: Nokogiri was built against LibXML version 2.7.3, but has dynamically loaded 2.7.8

[Brian Henderson]

It seems like it's building against one version of libxml and running against another. Is there a way to properly fix this besides disabling mini_portile on install?

thanks,

On Thursday, October 10, 2013 12:45:38 PM UTC-7, Brian Henderson wrote:

[Kenneth Stailey]

The link loader ("/bin/ld" or "/usr/bin/ld") has an option "-R" for specifying a list of directories to search at runtime for shared libraries.

In the past nokogiri did not supply libxml2 so there were lots of posts about it failing to link and the thought was to add a copy of libxml2 to the nokogiri package so no one would suffer.

Unfortunately, nokogiri does not use the "-R <path>" option so it compiles with one library and runs with another.  It should be using "-R <path>" to point to the libxml2 that it comes with.

Normally "-R <path>" is passed to gcc or g++ and that hands it to ld.

[Mike Dalessio]

Brian,

You can tell Nokogiri to use the installed version by setting this environment variable: NOKOGIRI_USE_SYSTEM_LIBRARIES=1

However, libxml 2.6.26 is extremely buggy and is unsupported. I'm going to try to reproduce this on a CentOS 6 virtual machine.

-mike

--
You received this message because you are subscribed to the Google Groups "nokogiri-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nokogiri-tal...@googlegroups.com.
To post to this group, send email to nokogi...@googlegroups.com.
Visit this group at http://groups.google.com/group/nokogiri-talk.
For more options, visit https://groups.google.com/groups/opt_out.

[byrnejb]

On Monday, 18 November 2013 06:53:58 UTC-5, Mike Dalessio wrote:

Brian,

You can tell Nokogiri to use the installed version by setting this environment variable: NOKOGIRI_USE_SYSTEM_LIBRARIES=1

Is there a way to tell Bundler to build nokogiri using the system libraries?  I placed BUNDLE_NOKOGIRI_USE_SYSTEM_LIBRARIES: '1'  in .bundle/config but I am receiving the same error regardless. 

[Ben Langfeld]

Try:

NOKOGIRI_USE_SYSTEM_LIBRARIES=true bundle install

--

[Mike Dalessio]

Try:

bundle config build.nokogiri --use-system-libraries bundle install

[John Smart]

This no longer works as of nokogiri 1.6.1.  I continue to get "WARNING: Nokogiri was built against LibXML version 2.9.2, but has dynamically loaded 2.8.0".  I find I'm fighting with Nokogiri more than any other gem.  Things seem to work, but the warning is distracting.  Does anyone know of a way to get Nokogiri to use the same compiled library at runtime, or at compile time to use the 2.8.0 that I suppose is packaged with it?