Perl and Apache Upgrades for Intel Mac (Pain)

pudge on 2007-12-30T06:31:26

I have been using a MacBook Pro for several months, and I finally got around to upgrading Perl on it. I figured 5.10's release, and Christmas vacation, was a decent opportunity. I ran into a lot of problems.

  • First, note that my existing Perl/Apache installs were PPC. And this is an Intel Mac. And because some systems are not very careful about what they use to do things, I had to make sure I basically hid all the PPC things in my path. For example, a PPC perl in my path was used for part of the mod_perl build process, even though I used an Intel perl for the Makefile.PL, which caused some symbols to go missing.
  • Similarly, the Apache config kept picking up a random library I had in /usr/local/lib, and throwing errors. So I finally figured I should just move all of /usr/local/bin and /usr/local/lib out of the way until I got everything built. I selectively brought things back later.
  • But this was not my only problem with Apache. Oh, no. Apparently mod_perl 1.30 and perl 5.10 simply do not get along. I kept getting errors about bad file descriptors every time I tried to start Apache. I finally found discussion from p5p about it, from a few weeks ago, and used Andreas Koenig's patch for mod_perl, taken from Steve Hay's fix slated for mod_perl 1.31. This fixed the problem, apparently.
  • However, apparently this patch only works for fixing non-threaded perl. So I then had to rebuild perl to be non-threaded. I had wanted to keep my perl config as close to the default Mac OS X build as possible, for binary compatiblity reasons, but it's not that important, I suppose, since 5.8 and 5.10 are not binary compatible anyway, and Mac OS X 10.6 (the first likely to use 5.10.x) won't be out for a long time. So, I don't need threads, and therefore, non-threaded it is.
  • And then there was libapreq. I don't know how to properly solve this problem, but I kept getting errors about my_perl being undeclared in two functions, hooks for uploading files. As I don't use that functionality, I simply commented out the body of the functions. It was getting late.
  • Most of the other modules were pretty smooth though. DBD::mysql kept looking for the mysql libraries in /usr/local/mysql/lib/mysql instead of /usr/local/mysql/lib. I couldn't see an obvious reason why, so I just added a symlink. Shrug.
  • Also, Mac::Carbon had some errors in the tests. Those should be fixed, but I have a lot of other fixes to make before uploading a new version. More on that some other time. The broken test was for Mac::AppleEvents, and I even have a comment in there about how the tests were very likely to be broken. I was right!
  • Mac::Glue posed a problem: the glue files are not byte-order independent. Maybe they should be, but that won't help me now. So I needed to rebuild all my glue files, which isn't a big deal.
  • Also not byte-order independent: the "friends" field in the Slash database. Like the glue files, it uses Storable. I know there are ways to make it work, but I did not use those ways previously, so now I am stuck. For Slash, I just wrapped the thaw() call in an eval for now, but I'll pull that later, after I call the rebuild task.
  • Speaking of modules, what got all this started was that I was trying to build XML::LibXML for my MacBook Pro so I could use XML::Atom to make posts from BBEdit to <pudge/*>. But building a PPC binary for an Intel machine ON an Intel machine turned out to be just too much for me. So I figured it was time to just start over.
  • The CPAN autobundle worked pretty well, although after installing Bundle::CPAN and Bundle::Slash, I then took my autobundle and wrote a quick script around it to basically call perl -M$module -e1 and note any errors, and that way I could skip most of the bundle, since I am still using the pure perl version of many modules, that I already had installed, and I don't necessarily want to install every upgrade to every module, since some of them can break (cf. XML::RSS). Then I scanned the uninstalled/broken module results and installed any I wanted by hand.
  • I make note here that Data::JavaScript::Anon is "still broken." Version 0.9 is broken, version 1.00 works, but CPAN still gives me version 0.9 unless I ask for 1.00 specifically, and so when I installed Bundle::Slash, I got the wrong one. But that has nothing to do with this, it's just Something Else.
Bottom line is that now I have Slash running on my Intel Mac with native Apache 1.39, mod_perl 1.30 (with patch), and perl 5.10 (without threads), and the only brokenness -- that I know of -- that remains is missing functionality in Apache::Request that I don't use, and lack of thread-capable perl for mod_perl. It was a long day making all that work, too. Dang it was long. Lots of futzing around. But I also now apparently have almost no more PPC apps running on a regular basis on my Mac: just Eudora. Which sucks. But not as much as every other mail app. I dunno, maybe I should give Thunderbird another go. I hate that it is not a native Mac UI, but it's not like Eudora has a great UI either. Maybe I'll try Mail.app again.

Cross-posted on <pudge/*>.


Been there.. still stuck

Beatnik on 2008-01-02T20:14:37

If you google plenty, you'll stumble upon tons of mails and posts about some of these topics. I'm still stuck on getting DBD::mysql to work in mod_perl (CGI, console and make tests work fine.. the symlink didn't work for me). Apache::Request compiled good enough. DBD::Postgresql is also giving some problems but I stopped halfway (holiday season priorities). All these things worked fine on my Intel Tiger but on Intel Leopard with perl 5.8.8 it freaks out :(

Re:Been there.. still stuck

pudge on 2008-01-02T20:53:19

Well, I seem to have it all working now for Apache 1.39/mod_perl 1.31/perl 5.10 nonthreaded under Intel Leopard (except for the upload hook stuff in Apache::Request), including DBD::mysql in mod_perl. If I can help any, ask away.

Re:Been there.. still stuck

Beatnik on 2008-01-02T21:22:00

My error_log dumps the following:

dyld: lazy symbol binding failed: Symbol not found: _mysql_server_init
Referenced from:
/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundl e
Expected in: dynamic lookup
The full post on the DBD::mysql listing is here. It pretty much details what I did and tried :)

Re:Been there.. still stuck

pudge on 2008-01-02T21:35:20

Are you trying to compile a universal binary? I've never tried to do that.

Re:Been there.. still stuck

Beatnik on 2008-01-02T22:10:33

When I stick to -arch i386 -arch x86_64, it throws the same error. Using either of those individually throws the typical image error.. I'm a complete newbie when it comes to building stuff on Mac :)