Sherm Pendley wrote: > No need to wonder about what it's doing - just watch the output when > you configure and make Perl, and then you'll know for certain. > > The answer to your question is, no, the Perl compile/installation does > not do any relinking for things that were linked against libperl. The > reason for this is simple and obvious: Perl's configuration script has > no way of knowing what those "things" are, or where to find the source > code with which to recompile them. The same applies to Apple's updater.
That's what I would have thought, but the fact that the original recompile to 5.6.1 that did not break mod_perl made me "wonder". I was thinking, contrary to my instincts, that there might be some mechanism that keeps track of links (in reverse). Just a pure theory with little foundation as a logical path to prove or disprove. :) > Unless you know *precisely* what's going on - that is, what exported > symbols have changed between one library version and the next, and > what symbols are required by each application that uses that library - > you should always assume that changing a library will disturb > applications that require it. Yeah, that's the thinking I wish Apple would take when they push out a library update! :) >> Apparently this wasn't the case here. Since Apple has taken it upon >> themselves to hide the update process (definitely a good thing for >> ease of use), it seems they should also think about what happens when >> libraries are updated and handle it. > > > Handle it how? How is Apple supposed to know which of an infinite > number of library/module combinations you've installed? It's > impossible. They test their updates against a fixed number of known, > supported system configurations - anything else is terra incognito. Well, since Apple is the one pushing out the update to Apache (and related modules), they know what they're changing (including libraries). Although I have not verified this, I'm enclined to think that this update was solely a binary push, and not a compiled update. If it were the latter (which some (few) Software updates are), then the relinking would have occured and PK and I wouldn't be having this problem (and likely others). > Apple's policy on this is clear, and perfectly reasonable: The /System > folder belongs to Apple. The computer belongs to you, of course, and > you're free to change anything you like, but if you make changes under > /System, you're on your own. Yeah... true... however tell that to CPAN, which THEY installed! If I do a CPAN install on a module, it puts things under /System. Yeah, I know this, you know this, and now everyone on this list knows this... but a process that is generally considered safe, standard, and common (Perl module installations via CPAN) will do things a less tech savy person will not be aware of. And don't use the argument "they should be more tech savy"... because this isn't a eutopia, and Apple has to deal with their customers despite what "they should know". What they DO know, is that most Perl sites preach doing CPAN module installations left and right, and many of them will require an update to Perl. My problem is resolved.... it was only a minor headache. But to the bulk of Apple's customer, who are not as "*nix" oriented, it may be a bigger headache. And many of them are being told about the wonders of what OS X can offer (read: CPAN, perl, etc). This is not meant to be a flame... like I said, my problem is resolved, and I understand the problem and solution, and will be sure to remember to not trust what Apple says is being updated and dig into the update file myself... I'm just saying that it's a poor assumption for a business to make, that their customers (especially the bulk of Mac users) will understand the importance of relinking with library updates. Thanks for the input... I'm just glad I can tinker with mod_perl again on my PowerBook. Cheers, -Alex
