Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pudge (1)

pudge
  (email not shown publicly)
http://pudge.net/
AOL IM: Crimethnk (Add Buddy, Send Message)

I run this joint, see?

Journal of pudge (1)

Sunday December 30, 2007
01:31 AM

Perl and Apache Upgrades for Intel Mac (Pain)

[ #35243 ]

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/*>.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 :(
    • 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.
      • 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 [mysql.com]. It pretty much details what I did and tried :)
        • Are you trying to compile a universal binary? I've never tried to do that.
          • 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 :)