ftblog

In den letzten zwei Wochen habe ich an zwei Tagen einen ganzen Haufen Zeit darin
investiert, fdm auf Debians BSD Portierungen baubar zu machen (kfreebsd und
knetbsd).

Beide Debian Varianten nutzen jeweils den entsprechenden BSD Kern und ein
komplettes GNU Userland.

fdm benutzt kein wirkliches Buildsystem, wie die Autotools oder cmake.
Stattdessen setzt es auf zwei relativ einfache Makefiles; eines für das make der
BSDs und eines für GNUs make Implementierung.

Da die GNU/k*BSD Variaten von Debian beide, wie gesagt, mit einer GNU Toolchain
daher kommen, dachte ich (naiver Weise) es wäre ausreichend, im GNUmakefile (dem
Makefile, das nur von GNU make gelesen wird) den Abschnitt zu Linux auf
Linux+k*BSD zu erweitern. Und zwar mit folgendem Schnipsel aus der PORTING
Anleitung der kfreeBSD Leute:

ifneq (, $(filter Linux GNU GNU_%, $(shell uname -s)))

Per Cut-n-Paste ins GNUmakefile gesteckt, geschaut ob die Änderung den Bau
Prozess für Linux negativ beeinflusst (nicht der Fall), Paket fertig geschnürt
und Nico gebeten es hoch zuladen.

Das Ganze funktionierte natürlich nicht, denn der Test muss eher so aussehen:

ifneq (, $(filter Linux GNU GNU/%, $(shell uname -s)))

('GNU/' anstelle von 'GNU_').

Das kommt davon, wenn man es einfach drauf ankommen lässt.

Um es besser zu machen, nimmt man qemu her und installiert sich ein kfreebsd in
eine Imagedatei hinein. Gemacht, eingerichtet, rumgespielt. Läuft.

Der 'GNU/' Test macht die Sache schon besser, aber es funktioniert immer noch
nicht. Auf kfreeBSD scheint es das libc Feature zu MREMAP_MAYMOVE und Konsorten
nicht zu geben. Gut, nicht so schlimm, noch einen Test ins GNUmakefile, und
einen Testlauf gemacht:

make clean ; make depend all PCRE=1

Ha! Erfolg!1!!

Schnell in meinem debian_fdm Verzeichnis den alten BSD-Support-Patch mit quilt
verworfen und einen neuen, zu dem was in der virtuellen Maschine funktioniert,
hinzugefügt.

Den Bau sicherheitshalber nochmal unter Linux versucht. Klappt.

Riesig. Schnell noch die 'debian/changelog' Datei updaten. Geben wir dem Release
mal einen schön grossspurigen Namen:

* The "this time I tried kfreebsd in qemu" release

Nico wieder um einen Upload gebeten, und ein wenig abwarten. ...Nach einer Zeit
mal schauen, wie das Ergebnis auf dem GNU/kfreeBSD buildd ausschaut.

Natürlich funktioniert das Bauen dort immer noch nicht... WTF!? Kann doch nicht
sein.

Virtuelle kfreeBSD Maschine hochgefeuert, die neuen Dateien (die der buildd von
Debian auch hat) runtergeladen, Tarball entpackt, den Debian spezifischen Patch
eingebaut, und 'debuild' gestartet.

Und tatsächlich, es funktioniert nicht. Gibt's doch garnicht. Sollte ich beim
Übernehmen der Änderungen tatsächlich Mist gebaut haben?

diff meint zumindest, ich hätte alles richtig gemacht. Komisch. Nochmal von Hand
einen Bau angeworfen:

make clean ; make depend all PCRE=1

Funktioniert. Die 'debian/rules' Datei wirft eigentlich auch nichts anderes an.

Aber der debuild Lauf bringt trotzdem mehrere Fehler beim Linken am Ende des
Baus; alle aus dieser Liga:

parent-fetch.o: In function `__sigdelset':
/usr/include/bits/sigset.h:133: multiple definition of `__sigdelset'
connect.o:/usr/include/bits/sigset.h:133: first defined here

Oh, ach ja:
make -f debian/rules clean build

...läuft durch. Fehlerfrei. Was in Dreiteufelsnamen macht dpkg-buildpackage denn
da bitte? Ehrlich, keine Ahnung. Und eigentlich habe ich auch keine Zeit mich
darum ausführlich zu kümmern. Manchmal möchte Murphy echt in die Finger
bekommen...

Natürlich hat die Geschichte auch eine Moral:
Don't ever fuckin' say: It can't *POSSIBILY* go wrong...