Re: DBI - DBD - mysql on Yosemite

Hi Michael,

please keep dbi-users@ in cc ;)

Am 29.10.2014 um 14:37 schrieb Michael Ahrweiler <[email protected]>:

> Hi
> 
>> Am 29.10.2014 um 10:49 schrieb Jens Rehsack <[email protected]>:
>> Am 28.10.2014 um 17:45 schrieb Michael Ahrweiler <[email protected]>:
>> 
>>> Hello
>> Hi Michael,
>> 
>>> It is not, that it does not function.
>>> It did. 
>>> mysql was just not starting at boot time. So I updated. Since then, it’s a mess.
>>> 
>>> After installing the latest mysql community-version 5.6.21
>>> On "make test" of DBD I get:
>>> 
>>> #   Failed test 'use DBD::mysql;'
>>> #   at t/00base.t line 18.
>>> #     Tried to use 'DBD::mysql'.
>>> #     Error:  Can't load '/temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle‘
>>> for module DBD::mysql: dlopen(/temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle, 2):
>>> Library not loaded: libmysqlclient.18.dylib
>> 
>> Where is this libmysqlclient.18.dylib from?
> see answer to otool-question

Already expected ;)
Smells like that (from "So I updated ...").

>> What is /temp?
> it is a near root-level folder from where I install those things
> As I said, this error came at "make test“ but is similar to what the web pages will say when I install anyway.

Maybe you should use this experience to tell people why "skipping 'make test'" isn't reasonable ...

>> What says 'otool -L /temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle‘?
> it says
> /temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle:
> 	/usr/local/mysql/lib/libmysqlclient.16.dylib (compatibility version 17.0.0, current version 17.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
> 
> There you have libmysqlclient.xx.dylib.
> It says 16 now, because I re-installed mysql-server 5.1.63.  With 5.6.21 it is 18.

What was the output of "otool -L /usr/local/mysql/lib/libmysqlclient.18.dylib"?

> Roaming at the same spot (actual mysql-folder in /usr/local) -- but somehow being part of the trouble.

Play a bit around with stuff like dports, pkgsrc ...
You'll detect some nice variables there named "<library>.ABI >= x.y.z" or "<library>.API >= ..."
And always "make clean" :D

> SPOILER HERE !!!
> 
> Dumping my bases, getting rid of the receipts and
> re-installing the 5.1.63 -- plus the actual dbi and dbd -- DID IT !!
> Perl works again with them mysql databases !!
> Still Yosemiting, no croaking…
> 
> So … it may be the combination of Yosemite AND version 5.6.21 that will run into these troubles.
> (Of course, I would not test the combination Mavericks and 5.6.21, too late for that.)

I do not expect that. I expect that there is another library causing the failure and you didn't track it down.

>>> #   Referenced from: /temp/DBD-mysql-4.028/blib/arch/auto/DBD/mysql/mysql.bundle
>>> #   Reason: image not found at /System/Library/Perl/5.18/darwin-thread-multi-2level/DynaLoader.pm line 194.
> 
> Just an idea for tracing…
> I looked up Dynaloader.pm line 194 and there is a comment before the croak command, 
> that says…
> 
>     # Many dynamic extension loading problems will appear to come from
>     # this section of code: XYZ failed at line 123 of DynaLoader.pm.
>     # Often these errors are actually occurring in the initialisation
>     # C code of the extension XS file. Perl reports the error as being
>     # in this perl code simply because this was the last perl code
>     # it executed.
> 
> before continuing
> 
>     my $libref = dl_load_file($file, $module->dl_load_flags) or
> 	croak("Can't load '$file' for module $module: ".dl_error());
> 
> Well, I heard that croak a lot…
> 
> I would/could not follow that track – dunno my way around things enough.
> Which xs might be the one in this case ?
> 
>>> Is there a path ?
>> There is always a path - but what dedicated path are you looking for?
> that was just a way of speaking

I just couldn't guess what was asked for ;)
Way of debugging? Location to search for libs? ...

> The path here is not really inside a computer…
> (meanwhile the one inside the machine i.e. the file system, might be decisive by the times we live)
> 
> very happy to be up and running again

Cheers
-- 
Jens Rehsack
[email protected]