libpthread heißt sie normalerweise.
find / -name ‚libpthread.*‘
und in der /etc/ld.so.conf muss sie drinstehen.
Es gibt nur diese drei hier:
root@des1 ~ # apt-get install libpthread-
libpthread-stubs0-dev libpthread-workqueue0 libpthread-workqueue-dev
Es gibt diese Dateien:
root@des1 ~ # find / -name 'libpthread.*'
/usr/lib/x86_64-linux-gnu/libpthread.so
/usr/lib/x86_64-linux-gnu/libpthread.a
/lib/x86_64-linux-gnu/libpthread.so.0
Aber die Ausgabe von folgendem ist leer:
root@des1 ~ # cat /etc/ld.so.conf|grep pthreadMal ganz von vorne. Wenn man anfängt Symlinks selber zu setzen, ist man meistens schon falsch abgebogen.
Hast du überhaupt die Build-Dependencies installiert? Mach mal alle komischen Symlinks rückgängig und führe erstmal folgendes aus:
# apt-get install build-essential
# apt-get build-dep isc-dhcp
Dann hast du direkt schon libbind-export-dev (was imo die Lösung für die erste Hälfte des Thread war). Eventuell fixt es direkt auch das aktuelle Problem, weil libpthread eigentlich Teil der glibc ist.
Kann natürlich sein, dass du dann immer noch fehlende Abhängigkeiten hast (weil du ja mit dem build-dep Befehl logischerweise die Abhängigkeiten der älteren Debian-Version installierst), aber da sich da normalerweise nicht allzu oft was ändert hast du vielleicht so schon Glück.
Und natürlich:
Immer wenn du neue Abhängigkeiten instalierst musst du immer noch ./configure neu ausführen. Das configure-Skript ist genau dazu da um zu schauen, was auf dem System genau installiert ist.
EDIT: NVM, habs jetzt selber nochmal probiert. Der mitgelieferte Bind hat eine merkwürdige Ordnerstruktur zu der ein „normaler“ Bind irgendwie nicht kompatibel ist. Symlinks sind also vermutlich doch der wa to go 
Okay, das klingt nach einem guten Ansatz. Die Buildabhängigkeiten habe ich gerade mal installiert.
Würdest du das bind-git weiterhin als Subrepo dhcp/bind hinterlegen oder würdest du da mit Include arbeiten? Eigentlich wäre es mir lieber, das gegen das Bind von Debian zu bauen. Wenn das nicht geht, natürlich alternativ gegen das aktuelle.
Kannst du mir einen Tipp geben, wie ich make/configure sage, dass Bind nicht in dhcp/bind liegt sondern im Debiansystem?
PS: Ich habe gerade nochmal frisch angefangen und trotz der build-deps kommt wieder derselbe Fehler:
make[1]: Entering directory '/root/gits/dhcp/common'
Making all in .
make[2]: Entering directory '/root/gits/dhcp/common'
gcc -DHAVE_CONFIG_H -I. -I../includes -I.. -DLOCALSTATEDIR='"/var"' -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I../bind/include -MT alloc.o -MD -MP -MF .deps/alloc.Tpo -c -o alloc.o alloc.c
In file included from ../includes/dhcpd.h:91:0,
from alloc.c:29:
../includes/omapip/isclib.h:51:24: fatal error: isc/buffer.h: Datei oder Verzeichnis nicht gefunden
#include <isc/buffer.h>
^
compilation terminated.
Makefile:456: recipe for target 'alloc.o' failed
make[2]: *** [alloc.o] Error 1
make[2]: Leaving directory '/root/gits/dhcp/common'
Makefile:519: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/root/gits/dhcp/common'
Makefile:437: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
Soll ich die Symlinks wieder reinmachen oder hast du eine andere Idee?
Must du wieder reinmachen, da die Struktur nicht ganz stimmt.
wenn man schon ein Paketmanagement basierendes System benutzt, dann macht man auch Pakete… 
Ich hab einfach mal auf meinem Jessie-Paket-Builder die aktuelle Version aus sid gebaut (die haben nämlich schon ein Paket von 4.3.5-b1) und im Build noch --enable-binary-leases und --enable-delayed-ack forciert - die passenden Abhängigkeitpakete aus bind9 liegen auch dort oben…
Disclaimer: Ich habe nichts getestet oder auf (Versions-)Inkompatibilitäten mit einem Live-System bzgl anderen Paketen ausprobiert… Ich hab nur geschaut, dass es baut
Shiva
Im Endeffekt dpkg-buildpackage … aber dazu muss noch einiges vorher passieren… 
Also grob umrissen und ohne Vollständigkeit oder gar Vorschlag, das so nachzumachen (und es gibt da hömmele verschiedene Vorgehensweisen - und meine ist wahrscheinlich eher nicht dokumentationswürdig, ja will sogar sagen »do not do this at home - we are trained professionals™« aber sei’s drum:
Ich habe für einige Distros jeweils LXC-Container, die quasi aus debootstrap genau dafür erstellt wurden/werden. (natürlich kann man das auch zum Paketbauen automatisieren - dafür gibt es diverse (meistens leider unterdokumentierte) fertige Lösungen…).
Dann schaut man bspw auf packages.debian.org, ob es in einer höheren Dist-Version das gewünschte Paket schon als Vorlage gibt und baut es »einfach« auf der niedrigeren Dist-Version in dem Container… oft geht das erfreulicherweise schon.
Manchmal (so wie hier) braucht man eben noch andere Abhängigkeiten - welche genau, sind in debian/control eingetragen und ploppen beim Aufruf von dpkg-buildpackage hoch. Wenn man die dann rekursiv bis runter erfüllt hat, dann sollte nachher ein passendes Paket herauspurzeln …
Klingt alles ein bisschen theoretisch.
Also ich nehme irgendwie die Quellen von 4.3 und baue die dann auf Debian 8 mit dpkg-buildpackage?
das sind die relevanten Seiten:
https://packages.debian.org/source/sid/isc-dhcp
https://tracker.debian.org/pkg/isc-dhcp
und brauchen tust du z.B. die drei auf der ersten Seite ganz unten verlinkten *.dsc, *.orig.tar.gz und *.debian.tar.xz.
Hast du die auf Platte runtergeladen, dann mit: dpkg-source -x isc-dhcp_4.3.5~b1-1.dsc auspacken/verarbeiten.
Anschliessend findest du ein neues Verzeichnis namens ./isc-dhcp-4.3.5~b1/.
Dort reinwechseln und dpkg-buildpackage aufrufen… sind alle Build-Dependencies erfüllt, dann purzeln die einzelnen *.deb-Pakete eine Ebene weiter unten raus…
Danke @Shiva, werde ich probieren.
Ein Grund mehr dieses ISC-Ding zu hassen. Das ist doch Murks. Gluon ist leichter zu kompilieren als das, weil eine gute Doku beiliegt.