MySQL Client Libraries

  • Worked on solutions for MySQL client library problem
Andrew DeFaria wrote:
Chris Davey wrote:

Andrew

have update the /apps/cmpackages as per the web page ane try the new version of mkview_linked but faile to run:

sunos

warmflash,a0741187> ./mkview_linked 
install_driver(mysql) failed: Can't load
'/apps/cmpackages/perl/lib/site_perl/5.8.0/sun4-solaris-thread-multi/auto/DBD/mysql/mysql.so'
for module DBD::mysql: ld.so.1: mkview_linked: fatal:
libmysqlclient.so.12: open failed: No such file or directory at
/apps/cmpackages/perl/lib/5.8.0/sun4-solaris-thread-multi/DynaLoader.pm
line 229.
at (eval 1) line 3
Compilation failed in require at (eval 1) line 3.
Perhaps a required shared library or dll isn't installed where expected
at ./mkview_linked line 54

warmflash,a0741187> ls -l
/apps/cmpackages/perl/lib/site_perl/5.8.0/sun4-solaris-thread-multi/auto/DBD/mysql
total 712
-r--r--r-- 1 amemgr ameadm 0 Mar 16 09:05 mysql.bs
-r-xr-xr-x 1 amemgr ameadm 360080 Mar 16 09:05 mysql.so*

linux

ace.tiuk.ti.com,a0741187> ./mkview_linked
install_driver(mysql) failed: Can't load
'/apps/cmpackages/perl/lib/site_perl/5.8.0/i686-linux-thread-multi/auto/DBD/mysql/mysql.so'
for module DBD::mysql: libmysqlclient.so.12: cannot open shared object
file: No such file or directory at
/apps/cmpackages/perl/lib/5.8.0/i686-linux-thread-multi/DynaLoader.pm
line 229.
at (eval 1) line 3
Compilation failed in require at (eval 1) line 3.
Perhaps a required shared library or dll isn't installed where expected
at ./mkview_linked line 54
ace.tiuk.ti.com,a0741187> ls -l
/apps/cmpackages/perl/lib/site_perl/5.8.0/sun4-solaris-thread-multi/auto/DBD/mysql
ls:
/apps/cmpackages/perl/lib/site_perl/5.8.0/sun4-solaris-thread-multi/auto/DBD/mysql:
No such file or directory

The problem seems to be that you lack /apps/mysql/<version> which is what we used to build the DBD::mysql package. We are working on alternate solutions. Meantime could you try the following:

  • mkdir /apps/mysql
  • On Solaris (warmflash): rsync -rlz stashu.dal.design.ti.com:/apps/mysql/4.0.16 /apps/mysql
  • On Linux (ace): rsync -rlz drteeth.dal.design.ti.com:/apps/mysql/4.0.17 /app/mysql

Try mkview_linked. Let us know.

Meantime back at the lab...

Short version:

Nix the rsyncing of /apps/mysql and redo the rsync of /apps/cmpackages. We're put a copy of mysql under /apps/cmpackages. After refreshing your /apps/cmpackages area you should see an /apps/cmpackages/mysql directory. Then test mkview_linked again.

Long version (AKA the gory details...)

In order to get mkview_linked to use DBD::mysql, the Perl package of mysql must be compiled and installed. Perl packages often glue some subsystem's API (in this case MySQL), normally written in C or something like that to a Perl package (i.e. a .pm file). So on the one end we have architecturally dependent code (usually a .a or .so library) and on the other we have (hopefully) architecturally neutral and interpreted Perl code (the .pm module). Therefore the process usually involves a makefile, execution of gcc to compile the glue code between the Perl and the subsystem's API as well as installing into the proper place, all of these files.

When Perl then calls the module DynaLoader.pm gets involved to load the appropriate architecturally dependent libraries so that calls to the Perl subroutines flow through the glue code and the appropriate API is called.

Since architecturally dependent code is involved we need to build this for the different architectures that we support. Further, MySQL in particular, has it's own library, libmysqlclient.a, which contains the API itself. So the glue code (mysql.so) needs to locate and load the appropriate libmysqlclient.a before it can successfully call an API. Finally there are issues of the version number of the, in this case, client software and the server software. Suffice to say, this is not always easy stuff!

Oh and we need mention that we are also talking about a large corporation here with various sites and the like; in most cases MySQL's client libraries will not be available locally nor of the right version - IOW we cannot trust that the MySQL client libraries will be local.

Oh and did I mention that mysql is not officially supported by TI...

We had hoped that /apps/mysql/<version>, while not officially supported, would be widely available but on our first guinea pi... ah... test subject, TI UK, we found that not to be the case. It looked like we had two ways to go: either 1) copy the /apps/mysql/<version> over to the remote sites or 2) include the /apps/mysql/<version> trees under /apps/cmpackages as our own mini distribution. I've implemented the latter. Now refreshing your /apps/cmpackages tree will carry along the necessary MySQL client libraries necessary to support mkview_linked and friends in most situations.