<sect1 id="ch05-whystatic">
<title>Waarom statisch linken?</title>
<?dbhtml filename="whystatic.html" dir="chapter05"?>

<para>(Met dank aan Plasmatic voor het posten van deze tekst naar &eacute;&eacute;n van de LFS mailinglijsten waarop dit hoofdzakelijk is gebaseerd.)
</para>

<para>Bij het maken (compileren) van een programma, worden in plaats van het
	iedere keer weer opnieuw schrijven van alle functies bij het schrijven
	van een nieuw programma voor de omgang met
	de kernel, hardware, bestanden, enz. al deze functies bewaard in een
	library. glibc, die je later zult installeren, is &eacute;&eacute;n
	van deze belangrijke library's, waarin code staat voor alle
	basisfuncties die door programma's worden gebruikt, zoals het
	openen van bestanden, het afdrukken van informatie naar het scherm,
	en het krijgen van feedback van de gebruiker. Wanneer een programma
	wordt gecompileerd, worden deze library's met code gelinkt met
	het nieuwe programma, zodat dit programma gebruik kan maken van de
	functies in de library.
</para>

<para>Deze library's kunnen echter nogal groot zijn (libc.a bijvoorbeeld
	kan vaak zo rond de 2.5 MB zijn), dus wellicht dat je aan het programma
	geen aparte kopie van elke library wilt hebben gekoppeld. Stel je
	voor dat je een eenvoudige opdracht hebt als ls waaraan een extra
	2.5 MB is gekoppeld! In plaats van de library onderdeel uit te laten
	maken van het programma, of statisch te linken, wordt de library als
	een apart bestand opgeslagen, wat alleen wordt geladen wanneer het
	programma het nodig heeft. Dit is wat we dynamisch linken noemen,
	aangezien de library dynamisch wordt geladen, op moment dat het
	programma het nodig heeft.
</para>

<para>Dus nu hebben we een 1 KB bestand en een 2.5 MB bestand, maar nog steeds
	hebben we geen ruimte bespaard (behalve misschien RAM totdat de library
	nodig is). Het
	<emphasis>werkelijke</emphasis> voordeel van dynamisch linken zit hem in
	dat we slechts &eacute;&eacute;n kopie van de library nodig hebben.
Als zowel <filename>ls</filename> en
<filename>rm</filename> van dezelfde library gebruik maken, dan hebben we geen
twee kopie&euml;n van de library nodig, aangezien ze beiden de code uit 
hetzelfde bestand kunnen halen. Zelfs wanneer in het geheugen, delen de twee
programma's dezelfde code, in plaats van duplicaten in het geheugen te laden.
Dus besparen we niet alleen harddiskruimte, maar ook kostbaar RAM.
</para>

<para>Als het dynamisch linken zoveel ruimte bespaart, waarom dan
	alles statisch gelinkt? Dat komt omdat wanneer je met chroot je
	gloednieuwe (maar zeer onvolledige) LFS omgeving activeert, deze
	dynamische library's niet beschikbaar zullen zijn, omdat ze zich
	elders op het systeem in je oude directorystructuur bevinden
	(<filename>/usr/lib</filename> bijvoorbeeld) die niet toegankelijk is
binnen je LFS root (<filename>$LFS</filename>).</para>

<para>Dus om je nieuwe programma's te kunnen uitvoeren binnen de chroot
	omgeving, moet je ervoor zorgen dat de library's statisch zijn
	gelinkt wanneer je ze compileert, vandaar de 
<userinput>--enable-static-link</userinput>, 
<userinput>--disable-shared</userinput>, en 
<userinput>-static</userinput> vlaggen die in Hoofdstuk 5 worden gebruikt.
Eenmaal in Hoofdstuk 6 bouwen we als eerste de hoofdset met systeemlibrary's,
glibc. Zodra deze is aangemaakt, beginnen we met het opnieuw bouwen van alle
programma's die we in Hoofdstuk 5 compileerden, maar ditmaal dynamisch gelinkt,
zodat we voordeel kunnen trekken uit de ruimtebesparende mogelijkheden.
</para>

<para>En dat is waarom je die rare
<userinput>-static</userinput> vlaggen moet gebruiken. Als je probeert alles
zonder deze vlaggen de bouwen, dan zul je er snel genoeg achterkomen
wat er gebeurt zodra je de chroot omgeving van je nieuw
verminkte LFS systeem activeert.
</para>

<para>Als je meer wilt weten over Dynamically Linked Libraries, raadpleeg
	dan een boek of website over programmeren, vooral een Linux
	gerelateerde site.
</para>

</sect1>
