Well now, here’s an interesting problem I had with Perl on the new Mac Xserve running Intel Xeon 64-bit processors. One of our customer’s had a CGI website (cringes) and was using DBD::MySQL to access the MySQL database. Upon initial observations, permissions had been setup incorrectly and the httpd.conf file was not setup properly for CGI executables.
Past this, I find that the server has dependency problems. This was found due to the following error message in the /var/log/httpd/error_log file. The particular error was:
So, I proceed to install Perl modules. But wait, CPAN’s bitching about an upgrade to CPAN being available. Fine, let’s give it what it wants:
Cool, now time to move to installing DBI:
Now for the last bit, DBD::mysql:
Damn, talk about something unexpected. After reading a few emails, forums, and getting down right frustrated with everything, I find this email note. This isn’t completely correct, in that it turns out you don’t have to install another copy of MySQL in some temporary location for the libraries - you have everything you need, assuming you’ve already installed XCode Tools.
So, what DO you have to do? The following:
Understanding of why Perl was so broken
Well, it wasn’t exactly Perl’s fault. It’s MySQL that comes on Apple’s Xserve. Apple, you question with an unquestionable doubt in your mind? Yes, Apple. Check this out:
Now isn’t that funny! On my new Xeon Xserve, the architecture specifications (which for some odd reason appear in BOTH the cflags AND libs flags which normally appear ONLY in the cflags) are for BOTH ppc64 AND x86_64… AFAIK, this server is Intel 64-bit based, not PowerPC any longer. So, when Perl goes through and autoconfigures its switches, these architecture flags cause the tests to blow up because it’s expecting a completely different set of tools that are expected to work on the PowerPC architecture.
Anywho, it’s working now, and that make me (and my client) happy.