Next Previous Contents

13. Software vanuit de broncode opbouwen

Tot dusverre heb ik de aandacht gericht op wat de pakketten doen. Hier geef ik je wat aanwijzingen over het vanuit de broncode samenstellen van een minimaal Linux-systeem.

13.1 Hoe ik mijn systeem opbouw

Er zijn meer manieren om een systeem op te bouwen. Maar de wijze waarop ik het deed scheen te werken, dus wellicht dat je er iets aan hebt.

Ik maakte gebruik van een speciaal daarvoor bestemde machine, een oude Wang 386sx van vrijwel geen enkele waarde meer. Ik voerde een installatie van RedHat 6.0 uit als ``bron'' systeem, en kende een ``doel'' partitie toe waarop ik het systeem bouwde. In de oude Wang, heb ik een 3G harddisk als volgt gepartitioneerd:

        hda1     480M   waarop ik het systeem bouwde (``doel'')
        hda2      20M   bootpartitie voor het RedHat-systeem
        hda3      50M   swap
        hda4    2500M   extended partitie als hda5
        hda5    2500M   Red Hat 6.0 rootfile system (``bron'')

In wezen heeft het niet zoveel zin de logische partitie hda5 hinnen een extended partitie, hda4, te hebben. Dat is nu eenmaal wat Disk Druid van RedHat er tijdens de installatie van maakte. Je hebt slechts het basissysteem van RedHat nodig, plus nog de development tools en library's. Het nam ongeveer 250M diskruimte in beslag. Je zou deze oefening uit kunnen voeren met een 1G disk of 2 disks van 500M.

Oudere PC-hardware, voornamelijk 486'rs en eerder, hebben een ergelijke beperking in hun BIOS. Ze kunnen niet van een harddisk lezen voorbij de eerste 512M. Voor Linux is dit niet zo'n probleem, omdat het zijn eigen disk io doet, zodra het is opgestart. Maar om Linux op deze oude machines te laden, moet het ergens onder die 512M voorkomen. Daarom heb ik zowel de gehele doelpartitie als de kleine bootpartitie voor het bronsysteem onder de 512M grens.

Wellicht dat je het doelsysteem daadwerkelijk wilt gebruiken, in plaats van voor het simpelweg bouwen als leerervaring. In dit geval zou je wat verder moeten gaan dan wat in dit document is beschreven. Je zou gcc en andere development tools moeten installeren, zodat het systeem zichzelf zou kunnen bouwen. Zodra je hiermee klaar bent, zou je het ``bron''-systeem kunnen verwijderen en deze ruimte op het doel kunnen gebruiken. Misschien dat je er de /usr directory naartoe kunt kopiëren.

In de Wang zit slechts 8M RAM. Ik denk dat dit de belangrijkste reden is waarom het compileren van glibc 90 uur duurde Op mijn 486'r met 32M duurde het ``slechts'' 6 uur. Ik gok dat het 24 tot 48 uur geduurd zou hebben als ik 16M in de Wang had. De compilatie van de kernel duurde ongeveer 8 uur.

Ik maakte met mke2fs een ext2 bestandssysteem aan op de target partitie, en maakte met mkdir handmatig de directory's aan. Ik had het toendertijd niet bij de hand, maar het zou goed zijn de Filesystem Heirarchy Standard te volgen.

In het bestand fstab van het bronsysteem, stelde ik de doelpartitie zo in dat ze werd gemount op /mnt/target. Voor de meeste pakketten is een configuratie-optie beschikbaar waar ze moeten worden geïnstalleerd. Standaard is de ``basis'' directory voor de installatie van een pakket /, dat wil zeggen dat je het wilt installeren op het systeem waarop het wordt samengesteld. Ik gebruikte deze opties om de basisinstallatiedirectory in te stellen op /mnt/target. Om bijvoorbeeld een GNU-pakket in /mnt/target te installeren, configureer je het als volgt:

        ./configure --prefix=/mnt/target

Er treedt een probleem op bij deze benadering als een aantal van de pakketten op het doelsysteem recenter zijn dan de equivalente pakketten op het bronsysteem. Ik installeerde bijvoorbeeld ncurses 5 op het doelsysteem, maar op de bron stond versie 4. Bij het compileren worden standaard de headers en library's van het bronsysteem gebruikt. Om dit te herstellen moet je variabelen of configuratieparameters instellen waarmee je het vertelt waar het de headers en library's kan vinden, die je wilt gebruiken. Soms is het enige dat je kunt doet het bestand Makefile hacken. Als je de uitvoer bekijkt die wordt geproduceerd onderwijl een programma wordt gecompileerd, vertellen de -I vlaggen waar op zoek te gaan naar headers, en de -L vertellen het waar op zoek te gaan naar library's. Zoek naar een variabele genaamd LDFLAGS. Dit is waarschijnlijk waar je een paar van deze vlaggen in kunt voegen, en het kunt laten zoeken naar waar je wilt. Bijvoorbeeld in de Makefile voor het pakket procps kreeg ik het voor elkaar gebruik te maken van de juiste library's door

        -L /mnt/target/lib

toe te voegen. Door RedHat wordt LILO in het masterbootrecord geïnstalleerd. Voor het doelsysteem installeerde ik LILO in de bootsector van de doelpartitie. Vervolgens voegde ik in /etc/lilo.conf het volgende toe op het bronsysteem

other=/dev/hda1
        label=doel

en herstartte lilo. Dit heeft als effect dat ``doel'' één van de opties is, die LILO je bij de eerste keer booten geeft. Selecteer je dit, dan krijg je een second instance van LILO die het doelsysteem boot. Dit lijkt misschien gek, maar het biedt je de mogelijkheid het systeem dat je aan het opbouwen bent te scheiden van het systeem dat je gebruikt om het op te bouwen.

13.2 Diverse Tips

Als je een opdracht hebt met de naam thingy op een Linux-systeem met RPM, en wilt weten waar de broncode vandaan te halen, dan kun je de opdracht:

        rpm -qif `which thingy`

gebruiken. En als je een RedHat broncode CD hebt, dan kun je de broncode installeren met

        rpm -i /mnt/cdrom/SRPMS/what.it.just.said-1.2.srpm

Zodra je een bashprompt hebt, the next stage is to get your system able to self replicate. Ik heb dit nog niet gedaan, maar hieronder staan een aantal zaken die je hiervoor zult moeten installeren.

13.3 Meer informatie


Next Previous Contents