Re^2: MAC OS 10.6 upgrade breaks DBD:mysql

Thanks! I did some additional research and I believe the source of the problems above is a 64 bit MySQL database and 32 bit Perl - at least in the past I recall having to deinstall the 64 bit mysql program and install the 23 bit version for DBD to work. The fact that Perl 5.10 is supposed to support 64 bit now muddies those waters but, nevertheless, I did perform the 32 bit reinstall. I also was able to get DBD:mysql to compile properly. However, I am still getting errors when I run my script:

finhagens-macbook-pro:perl finhagen$ ./tme_ext_full.pl 
dyld: lazy symbol binding failed: Symbol not found: _mysql_init
  Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/aut
+o/DBD/mysql/mysql.bundle
  Expected in: flat namespace

dyld: Symbol not found: _mysql_init
  Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/aut
+o/DBD/mysql/mysql.bundle
  Expected in: flat namespace

Trace/BPT trap
[download]

I googled this error but I didn't find any references that explained how to fix this problem. Any suggestions?

Hagen Finley

Boulder, CO

Comment on Re^2: MAC OS 10.6 upgrade breaks DBD:mysql Download Code

Replies are listed 'Best First'.
Re^3: MAC OS 10.6 upgrade breaks DBD:mysql by romkey (Acolyte) on Sep 08, 2009 at 13:33 UTC
I'm running the stock Perl 5.10.0 that came with Snow Leopard, and it's definitely running as a 64 bit app on my machine. For me, the version of Perl 5.10.0 that shipped with Snow Leopard worked okay with a fresh install of 64 bit MySQL and clean build of DBD::mysql I wonder if you're seeing problems from multiple incompatible versions of Perl libs being installed or having a library path issue?	[reply]
Re^4: MAC OS 10.6 upgrade breaks DBD:mysql by DaGaMs (Initiate) on Sep 16, 2009 at 11:34 UTC
I did exactly the same: Install mysql 5.4.1beta 64bit binary from mysql developer website. recompile dbd::mysql. It SEEMS to work fine, but I am having a load of very very strange issues when selecting from tables with blob/text columns. Basically, what happens is that I get `NULL` return values sometimes. Sometimes in this case means not just sporadic, but reproducibly for one script while I'm testing it. However, it's also random, because changing the script, without changing any of the queries, suddenly causes the queries to return data. It's driving me nuts, this error. Yesterday I thought I nailed it, it seemed that always the last requested column of the query returned `NULL`. Today, I changed the query back to where it was failing yesterday, and suddenly it works again. I'm at a loss. I tried the DBD::mysql mailing list, noone had a clue there, either. Oh wise perl Monk, hast though any idea how to salvage my script? UPDATE Actually, I figured out why the behaviour is so unpredictable: The bug must have to do with the actual mysql server doing some caching: When I run a query on the table containing the TEXT column in Sequel (a mysql client for Mac), and then run the perl script immediately afterwards, it works. A few hours later, it doesn't work any more. Now how weird is that?!	[reply] [d/l] [select]
Re^3: MAC OS 10.6 upgrade breaks DBD:mysql by Anonymous Monk on Sep 13, 2009 at 16:59 UTC
I get the same error---except when I run my script as root using sudo. Why should it need, or even want, to run as root? To be more precise, `me% perl -MDBD::mysql -e 'print "hello\n"'` [download] works fine, as does `me% sudo perl checkin.pl` [download] (which connects to a database on another server, ie, not localhost). But `me% perl checkin.pl` [download] produces the error Hagen describes above. Any ideas would be most welcome. I am running 10.6.1. I ripped out my previous MySQL and DBD::mysql installations, reinstalled MySQL 5.1.38 for x86_64 using the package installer from mysql.com, and manually installed DBD::mysql 4.012 with Perl Makefile.PL, etc. There were an awful lot of warnings on "make". Perhaps it is relevant that "make test" failed but "sudo make test" succeeded. The error message from "make test" was to me uninformative. I will copy just the first few lines here: % make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_h +arness(0, 'blib/lib', 'blib/arch')" t/*.t t/00base....................ok 1/6 + # Failed test 'use DBD::mysql;' # at t/00base.t line 21. # Tried to use 'DBD::mysql'. # Error: Can't load '/Users/zteitler/Installers/DBD-mysql-4.012/b +lib/arch/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/ +Users/zteitler/Installers/DBD-mysql-4.012/blib/arch/auto/DBD/mysql/my +sql.bundle, 2): Symbol not found: _is_prefix [download] Any comments or suggestions would be most welcome.	[reply] [d/l] [select]
Re^4: MAC OS 10.6 upgrade breaks DBD:mysql by Anonymous Monk on Sep 13, 2009 at 19:31 UTC
I removed the following: `/Library/Perl /usr/local/mysql* /Library/Receipts - everything mysql /private/var/db/receipts - everything mysql` [download] Then I reinstalled mysql version 5.0, architecture x86 --- ie, 32-bit version, and all my Perl modules including DBD. No problem this time. Perhaps I could have gotten away with removing less stuff, I don't know. The following combination seems to be working for me: OSX 10.6.1, perl 5.10, 32-bit mysql version 5.0.51, manually installed DBI and DBD::mysql. Well, it is working at the moment, at least. Interestingly, the 64-bit preferences pane (swoon.net) seems to work okay with 32-bit mysql. I should say that I tried building DBD with the 64-bit versions of mysql 5.0, 5.1, and 5.4, and they all had problems (the problem in the original post). I didn't try with the 32-bit versions of 5.1 or 5.4. Since things seem to be working now---32-bit version of 5.0---I am not messing with it any more. Ever. --zteitler	[reply] [d/l]
Re^4: MAC OS 10.6 upgrade breaks DBD:mysql by Anonymous Monk on May 17, 2010 at 10:29 UTC
I had the same problem. I thought I had everything in 64-bit, however in my case I found that I had an environment variable set: `VERSIONER_PERL_PREFER_32_BIT=yes`. Unsetting this variable made Perl run in 64-bit. Root did not use this environment variable, which explains why it worked running with sudo.	[reply] [d/l]