When I was trying to automatically mount an encrypted image at login using pam_mount, I encountered a strange problem:
I wasn’t able to find any errors in my configuration (at least none connected to this behaviour), but mount.crypt was unable to mount the image.
Enabling debugging in pam_mount.conf.xml (<debug enable="1" />) revealed the command used for mounting:

pam_mount(misc.c:272) command: mount.crypt [-o loop] [/home/foobar/container] [/home/foobar/crypto]

In Debians libpam-mount 0.44-1+lenny3, /sbin/mount.crypt is a bash script that calls cryptsetup with parameters generated during its runtime.
Debugging it (set -x), I stumpled upon the following command:

cryptsetup -c aes -h ripemd160 -s 256 create _home_foobar_container /home/foobar/container

…which returned the following error message:

Command failed: BLKROGET failed on device: Inappropriate ioctl for device

So mount.crypt has been passed the loop option but cryptsetup was told to mount the encrypted image instead of the associated loopback device (normally mount.crypt executes losetup to create this association in its function _losetup, but this apparently has never been called).

Long story short:
There seems to be a bug in Debians libpam-mount 0.44-1+lenny3.
The case statement at line 110 in /sbin/mount.crypt doesn’t work as expected because the variable $KEY used for option comparison has an ordinary space at its values beginning.
To fix this, you can either change the way how passed options are saved in the OPTION variable (starting at line 60) or change line 110 to the following:

case ${KEY/ /} in

This will remove all spaces.

pdftk
pdftk ist eine Open Source Software, die es ermöglicht, PDF-Dateien per Kommandozeile zu bearbeiten. Zu den vielfältigen Features von pdftk gehört etwa die Möglichkeit PDFs übereinander zu legen.

pdftk statisch kompilieren

Einleitung
Möchte man pdftk statisch kompilieren, um es etwa auf einem Hetzner Managed Server betreiben zu können, müssen die mitgelieferten Java Bibliotheken statisch kompiliert werden. Um dies zu erreich genügt es sowohl bei pdftk 1.21 als auch bei pdftk 1.41, die Makefiles
anzupassen – von Änderungen am Quelltext bleibt man verschont. Es ist übrigens durchaus sinnvoll, pdftk als 32bit Applikation zu kompilieren, denn nur so läuft es auf nahezu jedem Linuxsystem – ohne dass man sich auch noch mit Cross-Compiling herumschlagen muss.

Makefiles anpassen
Nachdem man pdftk heruntergeladen hat, das Archiv entpackt hat und in das neue Verzeichnis gewechselt hat, gilt es die Dateien Makefile.Base und Makefile.DEINE-DISTRIBUTION bzw. Makefile.Generic anzupassen. Diese befinden sich im Unterverzeichnis pdftk.

Makefile.Generic / Makefile.DEINE-DISTRIBUTION
In der Datei Makefile.Generic (bzw. in der Datei, die make mit dem Parameter -f übergeben wird, z.B. make -f Makefile.RedHat) werden die Flags für den Gnu Java Compiler GCJ gesetzt:

# itext compiler flags
export GCJFLAGS=

Um GCJ anzuweisen, die (mitgelieferten) Java Bibliotheken statisch zu kompilieren, müssen die GCJFLAGS wie folgt geändert werden:
export GCJFLAGS= -static

In diesem Makefile werden auch die Flags für den C++-Compiler g++ gesetzt.
Default hat die Entsprechende Konstante in dem Makefile Makefile.RedHat folgenden Wert:
CXXFLAGS= -lrt -ldl -lgcj

Auch diese Flags müssen angepasst werden:
CXXFLAGS= -W1,-v -static -W1,-Bstatic -lgcj -lpthread -lm -lz -ldl -lrt -W1,-Bdynamic -lsupc++ -lstdc++ -lc

Die Flags, die mit “-W1,” beginnen, werden an den Linker ld übergeben. Abgesehen von libc, libsupc++ und libstdc++ werden alle Bibliotheken statisch gelinkt, um deren dynamische Versionen auf dem Zielsystem nicht erforderlich zu machen (auf den Managed Servern von
Hetzner ist beispielsweise keine (dynamische) libgcj installiert).

Makefile.Base
In der Datei Makefile.Base werden Konfigurationen vorgenommen, die weniger Distributionsabhängig sind, als jene in den anderen Makefiles. Der Entwickler von pdftk hielt sie offenbar sogar für komplett Distributionsabhängig, deshalb wird dieses Makefile von allen anderen
eingebunden. Für das Vorhaben pdftk statisch zu kompilieren ist sie eigentlich uninteressant – es sei denn man erhält (wie bei mir während des Linkens von pdftk 1.41 passiert) eine Fehlermeldung im Stil von “multiple definition of `convert’”.
pdftk liefert nämlich selbst alte Java Bibliotheken mit. Im Beispiel von Convert reicht es die betreffende Zeile im Makefile auszukommentieren, um das Problem zu beheben:

libgcj_local_libs = \
$(java_libs_root)/java_local/security/security.a \
$(java_libs_root)/gnu_local/java/security/provider/provider.a \
$(java_libs_root)/gnu_local/java/security/security.a# \
#$(java_libs_root)/gnu/gcj/convert/convert.a

Tücken
GCC Versionen
Die aktuelle Version von pdftk stammt vom 28. November 2006 – anders ausgedrückt: pdftk wird nicht mehr aktualisiert. Da sich die GNU Compiler Collection jedoch mit jeder neuen Version ändert und beispielsweise strikter wird, was Syntax angeht, lassen sich pdftk Version 1.21 sowie pdftk 1.41 am besten mit alten Compilern kompilieren. Ich habe pdftk 1.21 erfolgreich mit GCC 3.4.5 kompiliert sowie pdftk 1.41 mit GCC 4.0.4. Statt sein System hierfür vollzumüllen
kann ich die Installation von Fedora Core 2 in einer VM (z.B. der kostenlose VMWare Server) empfehlen.

Statische Libraries mit “falschen” (unerwarteten) Dateinamen
Während des Kompilierens von pdftk werden u.a. die statischen Bibliotheken libgcj.a und libgcc_s.a erwartet. Sind die entsprechenden Pakete (meist libgcc-devel, libgcj-devel o.ä.) installiert, kann es trotzdem sein, dass die entsprechenden Dateien nicht vom Linker ld
gefunden werden können. In meinem Fall hat sich libgcj.a unter dem Dateinamen libgcj_bc.so versteckt, libgcc_s.a hieß libgcc_s.so.1. Ein Symlink (ls -s) auf den richtigen Dateinamen behebt dieses Problem.
Die GCC Bibliotheken befinden sich bei Linuxdistributionen standardmäßig im Verzeichnis /usr/lib/gcc/*/.

GCC 4.0.4 auf Fedora Core 2 kompilieren
GCC 3.4 ist auf Fedora Core 2 bereits installiert. GCC 4.0.4 kann auf einem der zahlreichen GCC Mirrors heruntergeladen werden.

GCC 4.0.4 habe ich wie folgt konfiguriert / kompiliert / installiert:
tar jxf gcc*.tar.bz2
cd gcc-*
mkdir objdir && cd objdir
../configure --enable-languages=c,c++,java --prefix=/opt --enable-threads=posix && make && make -k check
make install