I asked my hosting service whether they were using the native ruby mysql
driver or the compiled version and they responded with “We use Ruby
gems”. Does that mean they use the native ruby driver? I don’t know
enough about the architecture to know whether the gem is the driver, or
just the api to the driver.
I asked my hosting service whether they were using the native ruby
mysql driver or the compiled version and they responded with “We
use Ruby gems”. Does that mean they use the native ruby driver? I
don’t know enough about the architecture to know whether the gem is
the driver, or just the api to the driver.
Thanks,
Bill
The “mysql” gem is the native C bindings.
– Ezra Z.
– Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)
I asked my hosting service whether they were using the native ruby
mysql driver or the compiled version and they responded with “We
use Ruby gems”. Does that mean they use the native ruby driver? I
don’t know enough about the architecture to know whether the gem is
the driver, or just the api to the driver.
Thanks,
Bill
Also if your host is running linux then you can tell for sure if
it’s the compiled driver from irb:
That was just what I needed to know. Here’s what happens.
When I run ‘gem list’ the list includes:
mysql (2.7)
BUT …
[email protected] [~/emrec]# irb
irb(main):001:0> require ‘mysql.so’
LoadError: no such file to load – mysql.so
from (irb):1:in `require’
from (irb):1
irb(main):002:0>
As I undertand the ruby-mysql library 2.7 does require the
libmysqlclient to be properly installed, and depending on the location
of mysql.so it is possible that rubygems is unable to load it, while
the library is actually using it…
Thank you for joining the thread. A follow-on question below.
Aníbal Rojas wrote:
As I undertand the ruby-mysql library 2.7 does require the
libmysqlclient to be properly installed, and depending on
the location of mysql.so it is possible that rubygems is unable
to load it, while the library is actually using it…
I’ve had other problems with this environment and its beginning to feel
like
maybe they’re all symptoms of one underlying, probably simple, cause.
The first involved BackgroundRb. Even though I had the line in
environment.rb uncommented to set RAILS_ENV to production, BackgroundRb
was
not picking it up and was writing the record of database access that I
do in
my worker to development.log. Invoking BackgroundRb with
‘RAILS_ENV=production /script/backgroundrb/start -d’ corrected that.
But
I’m still concerned because I have no idea why the behavior occurred in
the
first place.
Is it possible the two behaviors are both related to some underlying
problem?
I have the same problem, ie gem reports mysql (2.7) installed but irb
cannot find ‘mysql.so’, ie:
[root@heliosintranet ~]# irb
irb(main):001:0> require ‘mysql.so’
LoadError: libmysqlclient.so.15: cannot open shared object file: No such
file or directory - /usr/lib/ruby/site_ruby/1.8/i386-linux/mysql.so
from /usr/lib/ruby/site_ruby/1.8/i386-linux/mysql.so
from (irb):1
The odd thing is that “/usr/lib/ruby/site_ruby/1.8/i386-linux/mysql.so”
is present!
Other that this, I don’t have any other suggestion for you
And yes, you are right, on linux it should be probably added to
/etc/profile or ~/.bash_profile.
On linux, you should really add it to /etc/ld.so.conf (or in
/etc/ld.so.conf.d if your distro supports it) and run ‘ldconfig’ – that
sets it system-wide. See crle on Solaris for similar functionality.
On linux, you should really add it to /etc/ld.so.conf (or in
/etc/ld.so.conf.d if your distro supports it) and run ‘ldconfig’ – that
sets it system-wide. See crle on Solaris for similar functionality.
Ben
Thanks for this.
The previous suggestion with didn’t work since SUDO removes path
variables. But I’d like to try your suggestion. For now I have some
changes in deploy.rb to set the path: