I passed on installing Tiger, but
it looked like
Leopard
might be worth the upgrade
(and might have a side bonus that my new
iPod
might now work), so off I went.
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
my .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
notes
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
UNIX 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:
~/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>'
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
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
limits header
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:
- add
UseNewInfoFmtStrings=yes to $CVSROOT/CVSROOT/config
- adjust the
commitinfo script so that it took (and ignored) parameters " %r/%p %s"
Still to investigate further:
- With the updates to a variety of projects, I also noticed the appearance of a bunch
of
exefile.dSYM directories 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
--work-properly
option.
- Also,
c++filt has 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.
