On Monday, checklib was finally announced on debian-devel-announce, thanks to Andreas Barth for sponsoring the mail.

I got very positive reactions from a number of people, which is great. I got less friendly comments prior to the announcement (by one person) , and I'm happy this reaction wasn't representative for the rest of Debian.

It's nice that people show interest in the problem, there's currently a discussion on debian-devel if and how automatic checking (and fixing) could be added to debhelper. That would seriously rock, as it would be one of the faster ways to get the number of affected packages down.

It's also cool to hear that the GNOME people are fixing their .la files with 2.16 in order to cut down dependencies introduced by broken libtool files.

There are some other interesting things on the horizon on the technical side of the project, as automatically built dbgsym packages (containing debug symbols, Ubuntu does that already), and the idea Simon Richter already talked about, which could really cut down the work the release team has with library transitions.

The victim was a PowerMac 9500 with a 300MHz G3 CPU, 200Mb RAM, a 9G HDD (with OS9 installed), and a 2G HDD (blank).

I hooked up a PowerBook to see the serial console output, since OpenFirmware only talks over the serial line. Then I finally found floppy images that would boot actually boot. They were from Woody, so I did a netinst using boot-floppies.

Unfortunately the Linux didn't come up after reboot. After resetting the nvram I could at least boot MacOS again and then start Linux via BootX. It took quite some fiddling with quik and the nvram till I had the direct boot working.

Subsequently I upgraded to etch, but I couldn't get a 2.6 kernel to boot. First I got a bus error from the IMS TwinTurbo graphics card driver, then the kernel "forgot" where the initramfs was loaded, which turned out to be a grave bug in the Debian kernel images (#366620).

I wrote patches for both bugs and now I finally have Etch with Linux 2.6 working. Whee!

The only sad thing is that all this took the better part of last week :-/

When writing manual pages the question comes up when to use "-" and when to use "\-". The answer is actually quite simple. Use "-" whenever you want a hyphen and "\-" when you want a minus sign.

There are two exceptions though: In the name section, "\-" is used to separate program name from short description, as in "man \- an interface to on-line manuals".

The other exception is that you have to use "\-" for options/switches (-h, --foo, etc.). "\-" causes man to emit an U+002d Hyphen-Minus character, whereas "-" results in U+2010 Hyphen (in a unicode locale).

U+2d is the normal ASCII hyphen char, the one programs use to test for switches. So "\-" allows copy&paste from the manpage, while "-" doesn't.

Last monday I held a short talk about ELF objects and dynamic linking for the Debienna crowd. It went semi-well; people were quite interested but somtimes didn't seem to grasp what I was talking about. Which was probably my fault because I didn't spend enough time preparing the talk, being on a difficult subject to begin with.

Perhaps I'll talk about the subject again for maks, Rhonda and baumgartner (if they are still interested), since they weren't able to attend.

In case anyone cares, I've written up some notes about ELF, dynamic linking, symbol lookup and related stuff, covering most the thinks I talked about.

I needed to fix the elfutils build failure on ia64, but I didn't have access to such a machine. Fortunately Herbert Pötzl pointed out ski, an ia64 emulator for Linux.

Ski needs a custom guest kernel however, so I had to cross-compile that for ia64.

Setting up a cross-compiling toolchain on Debian is really easy nowadays; there's even a nice HOWTO describing the needed steps. For lazy people pre-built packages are available.

When compiling the toolchain yourself, note that you may need more/other library packages then listed in the HOWTO. This depends on the target architecture, e.g. for ia64 you will need libunwind7-dev, libatomic-ops-dev, and further libc6.1 instead of libc6. Otherwise gcc will complain about missing build-dependencies.

For ia64 I ran into a linker error when building gcc, however a patch from Bertl's cross-compiling corner solved that.

While doing all this I wrote some scripts to automate the process, so compiling a cross-toolchain (for any architecture) is now a matter of 5 minutes configuration and one ./driver run. Whee!