On Thursday, April 11, 2002, at 12:42 PM, Alex S wrote: > I wonder if the Perl compile/installation does the relinking for > things that were dependent on it (would be a good thing, making things > simple, and catching everything).
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. >> any time you make a system change like that it can disturb linkages, >> and >> that's exactly what you're seeing here... > > Can, but doesn't always. 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. > 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. 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. sherm-- Never put off until tomorrow what you can do today. There might be a law against it by that time.
