Each time i launch a script using Nokogiri i get :
WARNING: Nokogiri was built against LibXML version 2.7.7, but has
dynamically loaded 2.7.3
despit this warning the script works as expected.
what is the best way to get right libxml ?
my libxml is installed using MacPorts Ruby 1.9 too.
Nokogiri is installed rubygems of the ruby 1.9 installed by macports.
on Mac OS X you could use the homebrew package manager, it’s easy to
install and to use, I don’t use macports anymore.
libxml installed with homebrew:
brew info libxml2
libxml2 2.7.7
/usr/local/Cellar/libxml2/2.7.7 (293 files, 12M)
Elise
2010/9/8 Une Bévue [email protected]:
elise huard [email protected] wrote:
on Mac OS X you could use the homebrew package manager, it’s easy to
install and to use, I don’t use macports anymore.
Why did you stop using MacPorts ?
I have to look about that…
GitHub - Homebrew/legacy-homebrew: 💀 The former home of Homebrew/homebrew (deprecated)
libxml installed with homebrew:brew info libxml2
libxml2 2.7.7
http://xmlsoft.org
/usr/local/Cellar/libxml2/2.7.7 (293 files, 12M)
History for Library/Formula/libxml2.rb - Homebrew/legacy-homebrew · GitHub
thanks a lot 4 your answer !
I’m used to Debian and BSD style package managements, and Macports
always seemed slow, a lbit clunky and out of date compared to those
others (though obviously respect to macport maintainers for doing it).
When a program is not available on homebrew I usually install it from
source, though obviously the right course would then be to package it
for homebrew, I’m told that’s pretty easy.
but maybe this is a discussion for another mailing list 
2010/9/8 Une Bévue [email protected]:
elise huard [email protected] wrote:
I’m used to Debian and BSD style package managements, and Macports
always seemed slow, a lbit clunky and out of date compared to those
others (though obviously respect to macport maintainers for doing it).
When a program is not available on homebrew I usually install it from
source, though obviously the right course would then be to package it
for homebrew, I’m told that’s pretty easy.
but maybe this is a discussion for another mailing list
yes, for sure !
2010/9/8 Une Bévue [email protected]:
–
You just need to build Nokogiri against the new libxml2:
gem install nokogiri
(and you can remove the old one, if the version was older with gem
clean nokogiri)
elise: I think this has nothing to do with the packager, in any way
you still need to build the gem again against the library to match
version.
But, yes, homebrew will by default install in /usr/local, which let
you forget about --with-mylib-dir= option when installing a gem with C
extension.
(For my part I even had to rebuild Ruby when I moved to homebrew,
because it was referencing some gmkdir (from coreutils package) in the
RbConfig, which would cause gems using that to fail to build)
Benoit D. [email protected] wrote:
You just need to build Nokogiri against the new libxml2:
gem install nokogiri
(and you can remove the old one, if the version was older with gem
clean nokogiri)
fine thanks, works without warning right now, after doing :
$ gem clean nokogiri
and
$ gem install nokogiri
ah, sorry, I thought the problem was she didn’t have the right version
of libxml. sorry for the confusing advice.
elise huard [email protected] wrote:
ah, sorry, I thought the problem was she didn’t have the right version
of libxml.
that’s right however re-building Nokogiri with the given LibXML is ok.
On 8 September 2010 21:17, elise huard [email protected] wrote:
ah, sorry, I thought the problem was she didn’t have the right version
of libxml. sorry for the confusing advice.
No sorry, it is just for the sake of correctness
Hi,
I’m going to reply to this message because I have a couple of comments,
but there’s also a bit of what turned out for me and the developers in
my company rather important information…
On 2010-09-08, at 3:10 AM, Une Bévue wrote:
elise huard [email protected] wrote:
on Mac OS X you could use the homebrew package manager, it’s easy to
install and to use, I don’t use macports anymore.Why did you stop using MacPorts ?
I have to look about that…
I have been having a growing annoyance with MacPorts for a while,
nothing specific, but definitely there. I switched to homebrew a couple
of weeks ago on one of my machines then on another last Friday (that’s
Sept 10, the day after this thread, and I’m just reading this now).
The best thing about homebrew is that it’s i) fast; ii) I can
understand exactly what’s been done. It doesn’t have a lot of packages
that I used from MacPorts, but as Elise said, that’s easy enough to deal
with.
GitHub - Homebrew/legacy-homebrew: 💀 The former home of Homebrew/homebrew (deprecated)
libxml installed with homebrew:brew info libxml2
libxml2 2.7.7
http://xmlsoft.org
/usr/local/Cellar/libxml2/2.7.7 (293 files, 12M)
History for Library/Formula/libxml2.rb - Homebrew/legacy-homebrew · GitHub
This is the important part. The other machine I mentioned is one that
I’ve been using to develop a pretty substantial web application. We have
been having a peculiar problem with ruby-libxml for likely 18 months
now. We’ve eliminated the library from our code base in favour of
Nokogiri. The problem is a memory corruption error (we think caused by
traversals of the the DOM) that occurs some time after the fact as a
GC error. Over time, through a process of elimination over took a month
or two, we are convinced that it was the ruby-libxml library causing the
problem.
On Friday I switched to homebrew, rvm, using Nokogiri. The memory
corruption problem reappeared. After a lot of sweating and a little
googling and I found this blog post:
http://bennyfreshness.posterous.com/installing-nokogiri-with-homebrew-install-of
Please read that if you are using OS X. If you do what he says, for me
most importantly:
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
the problem goes away.
I am now suspicious that our problems with ruby-libxml were for the same
or similar reasons. libxml2 comes with OS X, maybe there’s some kind of
confusion there? Don’t know.
Anyway, you should probably build Nokogiri this way. The problem is not
apparent for some time after the actual damage was done. Short running
tests do not illustrate the problem, at least, we’ve not found one.
Cheers,
Bob
thanks a lot 4 your answer !
« Pour ceux qui vont chercher midi à quatorze heures,
la minute de vérité risque de se faire longtemps attendre. »
(Pierre Dac)
Bob H.
Recursive Design Inc.
http://www.recursive.ca/
weblog: Xampl.com is for sale | HugeDomains
Hi all,
Sorry for the silence from Nokogiri HQ on this one. Let me first say
that
I’m sad none of this discussion occurred on the nokogiri-talk mailing
list,
where it might be highly visible for someone to read in the future. I’d
like
to encourage people with Nokogiri questions, particularly questions
about
installation, to ask on nokogiri-talk first.
I’d also like to preface my remarks by saying that I think that
Installing Nokogiri - Nokogiri might have helped
anyone/everyone with this problem. If it needs to be edited, I’d love to
hear constructive feedback.
That said, comments inline below …
On Sun, Sep 12, 2010 at 9:10 AM, Bob H.
[email protected]wrote:
This is the important part. The other machine I mentioned is one that I’ve
been using to develop a pretty substantial web application. We have been
having a peculiar problem with ruby-libxml for likely 18 months now. We’ve
eliminated the library from our code base in favour of Nokogiri. The problem
is a memory corruption error (we think caused by traversals of the the DOM)
that occurs some time after the fact as a GC error. Over time, through a
process of elimination over took a month or two, we are convinced that it
was the ruby-libxml library causing the problem.
Well, there are two possible root causes for this. One is that, if
you’re
using a buggy version of LibXML (in particular, v2.6.16 that comes by
default with Leopard), then you will crash. It’s just a buggy version of
the
library. You’ll note that on
Installing Nokogiri - Nokogiri Nokogiri HQ
states in
no uncertain terms that 2.6.16 should not be used.
The other possible root cause is libxml-ruby, which has known issues
with
how it interacts with libxml’s (rather hairy) memory management, and
does
not appear at this point in time to be actively maintained.
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
They key point here is that, if you have two versions of libxml2
installed
on your machine, it’s necessary to be very careful that Nokogiri’s C
extension is compiled against the same version of libxml2 that is
dynamically linked (at runtime). Nokogiri will warn you if you “cross
versions”, e.g. compile against 2.7.3 but dynamically link in 2.6.16.
This
is another possible source of crashing / memory corruption.
This form of installation command is referenced at
Installing Nokogiri - Nokogiri under
“nonstandard
libxml/libxslt installations”, which I think we can all agree Homebrew
is
(i.e., nonstandard). Is there some way that page can be clarified to
help
future Nokogiri users?
I’m in complete earnest when I say I’m interested in your opinion. I’ve
even
open-sourced the Nokogiri.org tutorials to try to encourage active
participation: http://github.com/flavorjones/nokogiri.org-tutorials
because,
I think you all know, after a while developing a project, it’s not
always
obvious what documentation might be missing or unclear.
the problem goes away.
I am now suspicious that our problems with ruby-libxml were for the same or
similar reasons. libxml2 comes with OS X, maybe there’s some kind of
confusion there? Don’t know.
As I said, it may have been libxml-ruby, or the version of libxml2 you
were
using, or a combination of the two.
mike dalessio / [email protected] / http://mike.daless.io/ /
@flavorjones
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs