Fortran and c++filt

Discovered an added wrinkle to the missing c++filt problem, which is that the GNU Fortran compiler g77 seems (bizarrely) to need c++filt—and so generates errors on execution (it still seems to produce executable binary files, though).

I tried installing the old 10.3.9 tools/SDK off the Leopard DVD in the hope that there might be a c++filt lurking somewhere, but no joy (with either find or Spotlight).

In other news, it looks like the version of GraphicConverter that came bundled with the machine isn't coping well with Leopard. It doesn't always refresh/redraw its windows—leaving them grey and blank (until they're scrolled to force a redraw).

X11 in the Dock

OK, it looks like my X11 problems aren't unique to me.

Getting rid of .dSYM/ directories

So the new --work-properly option for this is to use -gstabs rather than plain old -g.

For Xcode projects, it looks like there's a choice of setting DEBUG_INFORMATION_FORMAT to one of stabs, dwarf or dwarf-with-dsym (where the last of these is apparently the default), but as far as I can tell the Xcode settings don't affect the proper way of doing things (the command line).

dvips and relative paths

Next oddity: dvips stopped finding figure files in a different relative directory:

dvips: Could not find figure file ../figures/lyapunov.ps; continuing

With a hint from this discussion, it looks like the appropriate --work-properly option is dvips -R0 … (although I've no idea why a relative path is considered a security hole, nor why this is now a problem given that I've not updated dvips).

gv and libXaw3d

Found another small application that's not working, namely gv. The error message is:

dyld: Library not loaded: /usr/X11R6/lib/libXaw3d.7.dylib
  Referenced from: /usr/local/bin/gv
  Reason: image not found
Trace/BPT trap

so as before I looked in /usr/X11R6 1/lib, and lo and behold, there's the relevant library.

A quick

/usr/X11R6 1/lib:ls /usr/X11R6/lib/*Xaw3d*
ls: /usr/X11R6/lib/*Xaw3d*: No such file or directory
/usr/X11R6 1/lib:sudo mv *Xaw3d* /usr/X11R6/lib/

and gv is good to go again.

Turning off the Spotlight

Almost certainly old news to 10.4 users, but when I plugged in an external hard drive, I noticed that Spotlight kicked off the process of trying to index it. Perusing a couple of useful web pages, it looks like the easiest way to stop this is just to add the external hard disk to the Spotlight Privacy list.

Upgrading from 10.3.9 to 10.5 (Leopard)

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.