lib/mysql.so: undefined symbol: vio_blocking

[tadman]

When compiled on Fedora 14 under Ruby 1.9 (p180 and p290) it will throw an exception that looks like this:

ruby: symbol lookup error: /usr/local/rvm/gems/ruby-1.9.2-p290/gems/mysqlplus-0.1.2/lib/mysql.so: undefined symbol: vio_blocking

What's unusual is that vio_blocking is actually not a function but a macro expressed as a #define in MySQL in violite.h.

The relevant part of mysql.c has this:

#ifdef HAVE_MYSQL_H
#include <mysql.h>
#include <mysql_com.h>
//#include <violite.h>
#include <errmsg.h>
#include <mysqld_error.h>
#else
#include <mysql/mysql.h>
#include <mysql/mysql_com.h>
//#include <mysql/violite.h>
#include <mysql/errmsg.h>
#include <mysql/mysqld_error.h>
#endif

You can see violite.h is specifically commented out and appears to be the source of this problem. It's not clear why this works on OS X but not Linux.

[tadman]

It looks like violite.h was present in earlier versions of MySQL 5.1, but is entirely absent in newer ones.

I think the vio_blocking method has been removed entirely in MySQL 5.5:

mysql  Ver 14.14 Distrib 5.5.14, for Linux (i686) using readline 5.1

[vanjabucic]

any workarounds regarding this issue?

[vanjabucic]

I made it work by commenting out code from static void optimize_for_async( VALUE obj )

what did that function really do?

[bassam]

Seeing the same issue on OSX Mountain Lion with mysql 5.6 and ruby 2.0 installed through home brew:

dyld: lazy symbol binding failed: Symbol not found: _vio_blocking Referenced from: /usr/local/Cellar/ruby/2.0.0-p0/lib/ruby/gems/2.0.0/gems/mysqlplus-0.1.2/lib/mysql.bundle Expected in: flat namespace

Is these a workaround for this?

[tmm1]

Use the mysql2 gem.

[vanjabucic]

People would if mysql2 supported prepared statements.

[PrimaryFeather]

I have the same problem on OS X Mavericks, using MySQL 5.6.13 and Ruby 2.0. Very annoying. :-( Could anyone who found a workaround describe it in more detail? Or is there a way we could fix this via a pull request?

[PrimaryFeather]

For OS X users who run into this problem: if you don't depend on using the very latest MySQL version, you can switch back to older version; for me, 5.5.27 worked well. If you're using homebrew, this Stack Overflow answer shows you how to switch back to such a version.

Of course, that's just a temporary workaround, but perhaps it helps someone.