DBD::mysql 4.004 .. does it actually compile at all on Solaris?

[simon simon]

Hi All,
I have spent the last week having my time wasted by the poorly implemented perl module. The developers have not been assistfully by the community on testing on Solaris IMHO.

I have seen so may posts that I am not alone... unfortunatly my c skills are not good enough except to try to imperically fix this issue.

Hope these tips may help fellow sufferers.

1) If you have solaris I would reccomend that you do not use the binary packages of mysql from eg sunfreeware. I have fond that these tend not to come with the dynamic libmysqlclient.so libraries (only the static .a's r iin the package). However if you compile mysql from source the required libraries get installed.

2) This also corrects the issues of the package mysql_config program incorrectly reporting the -xarch and -m perams in the the lib flags that DBD::Mysql uses
(This generates "unknown arch errors on compile)

3). Do not use symlinks in your LD_LIBRARY_PATH or PATH.
I like to build everything in /opt with multiple versions of the same app with the required version being the app name without version number being the symlink to the required directory with the version number appended.
However I have been caught out by "find"
getting confused by the symlinks and not finding the libraries that I am searching for under the symlink,, but it does if I find on the real directory name.

If it happens to me then maybe a script somewhere cam get caught out as well.. even if this makes no difference it may stop you getting confused as well.

Also make sure you can do a "find" and "which" on your required libraries from the account you are compiling the software under, especially libmysqlclient.so


4). I am beginning to wonder if a lot of these problems are caused by a mixture of 64bit code / libraries being referenced by 32bit perl modules. It may be worth checking -v options on mysql and perl to double check that the libraries and software versions of perl and mysql are all either 32bit or 64bit
(I am doing this tonight)

5). Do which on your gcc and make binaries, I have found I get less issues using gnumake and gcc rather than the supplied compiler with sun. eg use

'which make'

To determin if you are actually using gnumake you just installed of the supplied make with sun which will tend to have priority on your PATH statements

6). Although you may be able to make and make install the DBD::mysql perl modules. Always run 'make test'. If it fails the tests (like mine does) installing the module will just cause problems .. like in Bugzilla in my case

7). After all this work I now just have issues running make test.
I have also taken the time to create accounts to be configured with the
--testdb, --testuser --testpassword flags on the "perl Makefile-PL" options
to eliminate database access casuing the test to fail.

It seams to me that there are big testing gaps in the solaris / 32-64bit setups / gcc environments.

I hope this helps anybody and if I confuse the situation evern more I apologies


All ths work means I have got as far as failing "make test" with the following error

"install_driver(mysql) failed: Can't load '<my path to cpan DBD build>/mysql.so' for module DBD::mysql: ld.so.1 <my path to pearl binary>: fatal: relocation error: file <my path to cpan DBD build>/mysql.so: symbol mysql_sqlstate: referenced symbol not found at <mypath to pearl libs DynaLoader.pm line 230"

If I crack it I will let everybody know