Upgrading from 10.3.9 to 10.5 (Leopard)
After backing things up, I whacked in the install DVD and left it to run an upgrade. I had to deselect a few things to get it to fit on my nearly-full hard disk, but sadly I couldn't deselect all of the additional languages which appeared to need a bunch of space (presumably they were there from the 10.3 install, and the Leopard installer only allows upgrade/install not removal).
The install took about an hour and a half, and was mostly fairly smooth. However, there were a couple of serious
oddities afterwards: the Finder would only hang, and everything seemed to run very slowly. Relaunching the
Finder didn't help, but just as I was starting to get worried the problem went away after a couple of reboots.
(Bizarrely, the Finder problem seemed to affect my Emacs startup too—it didn't read
.emacs and showed an error message: "Finder got an error: Apple Event timed out.")
For the slowdown, I finally noticed the new magnifying glass in the top right corner of the screen, and discovered that it was due to Spotlight indexing the disk. Once it had finished (which I would guess took around 3 hours, but I left it overnight), the speed seems to be roughly back to normal.
The upgraded X11 seems to be the biggest step backwards so far. The upgrade lost my customized shortcut applications, and in trying to recreate them I discovered that it's no longer possible to include command line options for an application (so I've had to create shell scripts and execute them instead). More seriously, the interaction of X11 with the Dock gets confused, so I end up with a bunch of big "X" icons in the dock, and Command-Tabbing to a X11 doesn't bring any window to the foreground.
Trying to rebuild all of my source code projects failed miserably at first, but that was just because I hadn't upgraded Xcode yet. Once that was installed, things started to work much better—but a few chunks of my source code needed updating for the newer, stricter compiler (GCC 4.0.1).
Some things were a little more taxing, however. The new version of M4 (1.4.6) has a bug dealing with input files that don't end in a newline; the easiest way of dealing with this was just to add newlines.
My installation of xfig
disappeared during the upgrade, which is a bit of a problem as a lot of my older
projects rely on it. Consulting my
it looks like I originally got
xfig using the i-Installer, but that now fails to re-install
the package (and has dire warnings about the unsupported level of both the particular
package and the installer itself).
Spotlight may be spangly, but it didn't find where
xfig had gotten to. Good old
find, on the other hand, quickly determined that
xfig and friends had been
shuffled off to a separate
/usr/X11R6 1/bin/ directory. A quick
mv * /usr/X11R6/bin/ and all was sorted.
Another problem was what initially looked like a problem with the C++ compiler's internal header files:
However, skipping the "-I." on the command line made the problem disappear, so it looked like a name clash between one of my local header files and one of the system header files. Again, the magic of the UNIX command line (specifically~/text/recipes: c++ -I. -c temp.cpp /usr/include/c++/4.0.0/bits/locale_facets.tcc: In member function 'virtual long int std::collate<_CharT>::do_hash(const _CharT*, const _CharT*) const': /usr/include/c++/4.0.0/bits/locale_facets.tcc:2417: error: 'digits' is not a member of 'std::numeric_limits<long unsigned int>' /usr/include/c++/4.0.0/bits/istream.tcc: In member function 'std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>::operator>>(short int&)': /usr/include/c++/4.0.0/bits/istream.tcc:151: error: 'min' is not a member of 'std::numeric_limits<short int>' /usr/include/c++/4.0.0/bits/istream.tcc:152: error: 'max' is not a member of 'std::numeric_limits<short int>'
for ii in *; do find /usr/include/c++ -name $ii; done) found the culprit so I could rename it. (It was actually a local version of the
limitsheader file that I'd created ages ago to cope with the deficiencies of the previous version of the C++ compiler.)
Having made all of the required changes to my project files, I noticed a bunch of deprecation warnings when I checked them in to CVS. The net result of the instructions for getting rid of this was to:
- adjust the
commitinfoscript so that it took (and ignored) parameters "
Still to investigate further:
- With the updates to a variety of projects, I also noticed the appearance of a bunch
exefile.dSYMdirectories all over the place. According to the docs, since Xcode 2.4 these directories look to hold debugging information for generated executables, held separately from the executables themselves. Given that I never distribute binaries, I'd prefer the normal behavior of binding the debugging information into the executable file itself. So I guess I need to look for the appropriate
c++filthas gone missing. Not normally a big deal, but it's specifically needed for one particular old project of mine. It's normally in the GNU binutils package, so I'll start the hunt there.
- See if there's any solution to the X11 issues.