Eerste start

Veel beginnende Linux gebruikers weten niet hoe ze een programma moeten starten nadat het is geïnstalleerd. Het belangrijkste probleem daarbij is dat anders dan onder Windows vaak geen vermelding in het startmenu van de grafische desktopomgeving wordt opgenomen en geen icoon op de desktop of in het paneel wordt geplaatst. De oorzaak daarvan is dat Linux ook uitstekend zonder grafische desktopomgeving werkt en veel programma’s daarom niet voor die desktopomgeving geschreven zijn. Vaak zijn het tekstgeorienteerde programma’s die in een console moeten worden gestart. Ook komt het veel voor dat het weliswaar om grafische programma’s gaat maar geen programma’s die voor een bepaalde desktopomgeving zijn geschreven. En ook al zijn ze wel voor een grafische desktopomgeving bestemd wordt toch meestal alleen een vermelding in het menu opgenomen en worden er geen iconen gemaakt. Bovendien zijn er verschillen in implementatie van de grafische desktopomgevingen tussen de distributies, bijvoorbeeld tussen Fedora en SUSE, waardoor zelfs automatische opneming in het menu onmogelijk kan worden.

Een programma kan echter altijd vanaf de opdrachtregel worden gestart. We zullen eerst zien hoe dat in zijn werk gaat. Daarna gaan we kort in op andere startmethoden in een grafische desktopomgeving.

Start vanaf de opdrachtregel in een console

Wanneer een programma eenmaal is geïnstalleerd kan het meestal vanaf de opdrachtregel worden gestart door de naam van het programma gevolgd door de Enter toets in te tikken. Voorwaarden zijn dat het uitvoerbare programma dezelfde naam draagt als het pakket, en dat het in een directory is geplaatst waarin het systeem naar uitvoerbare programma’s zoekt. Al die directories maken deel uit van de omgevingsvariabele PATH.

Als dat niet werkt omdat de naam van het programma toch afwijkt van de naam van het pakket zult u in de documentatie van het pakket na moeten gaan hoe het programma dan wel heet. Als het niet werkt omdat het programma niet in een PATH directory staat kunt u proberen er in de documentatie achter te komen waar het programma is geïnstalleerd, of u probeert het te zoeken met de opdrachten find of locate. Met find geeft u de volgende opdracht:

find / -name <programmanaam> -print

waarin u voor <programmanaam> de juiste naam van het programma invult. Locate gebruikt u zo:

locate <programmanaam>

Locate maakt gebruik van een database waarin de lokatie van alle bestanden in het systeem is opgenomen. Deze database wordt wordt up-to-date gebracht met het commando updatedb. De meeste Linux distributies hebben het zo geregeld dat dit regelmatig, bij voorbeeld 1 maal per dag of per week, wordt gedaan. Als u echter net een nieuw programma hebt geïnstalleerd zal locate dit nog niet in zijn database kunnen vinden. U zult dan eerst updatedb even moeten draaien:

updatedb

Daarna kan locate u de lokatie van het programma geven.

Als het programma uit een binair pakket afkomstig is kunt een lijst van alle in het pakket opgenomen bestanden met pad en al opvragen. Met rpm gaat dat als volgt:

rpm -ql <pakketnaam>.rpm

Van Debian pakketten kunt u een lijst opvragen met:

dpkg -L <pakketnaam>.deb

en van tarballs met

tar -tzf <pakketnaam>.tar.gz
tar -tjf <pakketnaam>.tar.bz2

Wat het uitvoerbare programma is of wat de uitvoerbare programma’s zijn blijkt dan wel uit de context, in het bijzonder uit de directorynaam. Tevens ziet u dan in welke directory het programma is geplaatst. Als de directory bekend is kan het programma altijd worden gestart met de opdracht:

waarin <pad naar programma> staat voor het volledige directory pad naar het programma en <programmanaam> voor de naam van het programma.

Als het programma een grafische interface heeft verdient het aanbeveling het startcommando te laten volgen door het „en” teken „&”. In dat geval wordt het programma losgekoppeld van het console en kunt u tijdens het draaien van het programma in het console verder werken.

Starten in een grafische desktopomgeving

In een grafische desktopomgeving als KDE en Gnome kunnen grafisch georienteerde programma’s ook worden gestart vanaf een opdrachtregel die met een bepaalde toetsaanslag kan worden opgeroepen. Zo roept u in KDE of Gnome met Alt-F2 een opdrachtregel op waarin u de naam van het uit te voeren programma kunt tikken, zo nodig voorzien van directorypad en parameters.

De installatieprocedure van een programma dat voor een bepaalde grafische desktopomgeving is bedoeld maakt normaliter een vermelding in het startmenu van die desktopomgeving. U zult even moeten uitzoeken waar het programma in het menu is opgenomen. Daarna kunt u het starten door op die menu-ingang te klikken.

Onder desktopomgevingen als KDE en Gnome kan een icoon voor het programma op de desktop, of in het paneel wel handig zijn. Zo’n icoon wordt meestal niet automatisch aangemaakt, dus moet u het zelf doen. Volg daartoe de handleiding van KDE resp. Gnome.

Afhankelijkheden bekijken en oplossen

Als u programma’s niet via RPM of de Debian package manager hebt geïnstalleerd, en ook niet vanuit de broncode hebt gecompileerd, kan het gebeuren dat een programma niet wil starten omdat één of meer libraries ontbreken. Uw Linux systeem heeft een handig script, ldd, dat u een lijst geeft van alle gedeelde libraries (shared libraries, zoals DLL’s in Windows) waarvan de op de opdrachtregel genoemde programma’s afhankelijk zijn en dat ook aangeeft of het deze libraries op het systeem heeft kunnen vinden. Let wel, het werkt niet voor shell scripts, java programma’s etc., maar alleen voor programma’s en shared libraries in machinecode (wat in Windows exe dan wel dll bestanden zijn).

Een programma als cp voor het kopiëren van bestanden is van maar heel weinig libraries afhankelijk. De opdracht

ldd /bin/cp

geeft als uitvoer:

libc.so.6 => /lib/libc.so.6 (0x40027000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Van deze twee libraries zijn vrijwel alle programma’s afhankelijk: libc is de C library, en de ander verzorgt het laden van shared libraries. Een KDE programma heeft veel meer afhankelijkheden. Zo geeft

ldd /opt/kde3/bin/krusader

(directory als in SUSE, in Fedora en Mandriva zal het /usr/bin zijn) als resultaat:

libkparts.so.2 => /opt/kde3/lib/libkparts.so.2 (0x40017000)
libkio.so.4 => /opt/kde3/lib/libkio.so.4 (0x4004f000)
libkdesu.so.4 => /opt/kde3/lib/libkdesu.so.4 (0x402fd000)
libutil.so.1 => /lib/libutil.so.1 (0x4032c000)
libfam.so.0 => /usr/lib/libfam.so.0 (0x40330000)
libkdeui.so.4 => /opt/kde3/lib/libkdeui.so.4 (0x40342000)
libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0x4052f000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40553000)
libkdecore.so.4 => /opt/kde3/lib/libkdecore.so.4 (0x40558000)
libDCOP.so.4 => /opt/kde3/lib/libDCOP.so.4 (0x406cc000)
libdl.so.2 => /lib/libdl.so.2 (0x40706000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x4070a000)
libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0x40757000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40cff000)
libz.so.1 => /lib/libz.so.1 (0x40d30000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40d3f000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40d4e000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40e0e000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40e18000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40e30000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40e46000)
libm.so.6 => /lib/libm.so.6 (0x40e57000)
libc.so.6 => /lib/libc.so.6 (0x40e7b000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x40fa3000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4115a000)
libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x41170000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4119a000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x411db000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x411e3000)

Indrukwekkend nietwaar? Stel nu dat de vijfde library van boven, libfam.so.0 (de File Alteration Monitor), ontbreekt. We zien dan de volgende uitvoer:

[….]
libutil.so.1 => /lib/libutil.so.1 (0x4032c000)
libfam.so.0 => not found
libkdeui.so.4 => /opt/kde3/lib/libkdeui.so.4 (0x40330000)
[….]

Er kunnen meerdere oorzaken zijn van het niet vinden van een library:

de library is er wel, maar in een directory waarin niet wordt gezocht
de library is er wel, maar de juiste symbolische link ontbreekt
de library is er wel, maar niet in de gevraagde versie
de library is er echt niet

In welke directories zoekt Linux eigenlijk naar libraries? Wel, er zijn twee standaard directories voor libraries, /lib en /usr/lib, waarin altijd wordt gezocht. Lokaal geïnstalleerde libraries worden meestal echter in een eigen directory /usr/local/lib geplaatst. Daarnaast zijn er verschillende belangrijke systeemprogramma’s, zoals de grafische server Xorg, die een eigen library directory hebben (in dit geval /usr/X11R6/lib). Om Linux te laten weten in welke directories ook naar libraries moet worden gezocht staan deze allemaal opgesomd in het bestand /etc/ld.so.conf. Het kan wel eens gebeuren dat een zelf geïnstalleerd programma veel eigen libraries meeneemt en die in een eigen library directory neerzet (bij voorbeeld de browser Firefox). Die directory zal veelal nog niet in ld.so.conf zijn opgenomen met als gevolg dat Linux de libraries er in niet kan vinden. De oplossing is eenvoudig: zet in ld.so.conf ook een verwijzing naar de nieuwe directory. Vaak zorgt het installatiescript van zo’n programma er overigens wel voor dat zijn library directory in ld.so.conf wordt opgenomen.

Wat de tweede mogelijke oorzaak betreft, de officiele naam van de in het voorbeeld hierboven ontbrekende library libfam.so.0 is libfam.so.0.0.0. Het gedeelte 0.0.0 is het volledige versienummer. Als een programma door alle 0.x.x subversies wordt ondersteund zou het niet handig zijn om aan te geven dat het van versie 0.0.0 afhankelijk is. Het werkt immers ook met bijvoorbeeld versie 0.1.2. Daarom geeft het programma aan dat het afhankelijk is van versie 0. Maar libfam.so.0 zal niet worden gevonden als er alleen maar een libfam.so.0.0.0 is. Om die reden is er bij installatie van de library ook een symbolische link met de naam libfam.so.0 aangemaakt die naar libfam.so.0.0.0 verwijst. Net zo is er een symbolische link met de naam libfam.so voor alle programma’s waarvoor elke versie van libfam.so voldoet. In het voorbeeld hierboven had ik de symbolische link libfam.so.0 verwijderd, maar de eigenlijke library libfam.so.0.0.0 laten staan. Als gevolg daarvan kon ldd de library niet vinden. Het probleem wordt dus opgelost door in de directory /lib, waar de gezochte library is te vinden, een symbolische link met de juiste naam libfam.so.0 aan te maken:

ln -s libfam.so.0.0.0 libfam.so.0

In het derde geval wil een symbolische link ook wel eens helpen, namelijk in het geval het systeem een nieuwere versie van de library bevat die neerwaarts compatibel is met de oude versie. Stel dat er wel een library libfam.so.1.0.1 is met symbolische links libfam.so.1 en libfam.so. ldd kan de gevraagde libfam.so.0 dan niet vinden. Maar als libfam.so.1 compatibel is met libfam.so.0 volstaat toevoeging van een symbolische link met de naam libfam.so.0 om het probleem op te lossen. Let wel, ook als de nieuwe library niet compatibel is met de oude zal toevoeging van deze symbolische link er toe leiden dat ldd de library kan vinden. Het programma zal dan echter toch niet goed draaien en mogelijk zelfs crashen. In dat geval moet u proberen om de oude versie van de library ergens te vinden. Dat lukt misschien op de ftp site van uw distributie leverancier, die meestal nog wel enkele oudere versies van de distributie ter download heeft staan. Anders kan een zoektocht met Google uitkomst brengen.

Ook het omgekeerde is natuurlijk mogelijk: er wordt gevraagd naar een nieuwere versie dan op het systeem aanwezig is. Meestal is dat niet zonder reden. Het programma zal dan waarschijnlijk gebruik maken van nieuwe functies die de oude versie nog niet levert. Niettemin kunt u met een symbolische link proberen het programma van de oude library gebruik te laten maken. Als u alleen functies van het programma gebruikt waarvoor de nieuwe library nog niet nodig is zou het best goed kunnen gaan. Anders zult u toch naar de nieuwe versie van de library op zoek moeten gaan.

De remedie in het laatste geval, waarin de library er echt niet is, moge duidelijk zijn: u zult de library op uw systeem moeten installeren. Misschien heeft uw Linux distributie hem wel, maar had u hem niet geïnstalleerd. Zo niet dan zit hij misschien bij een nieuwere versie van uw distributie en kunt u hem via ftp downloaden. Anders zou u rpm’s met de library misschien kunnen vinden via rpmseek.com, rpm.pbone.net of rpmfind.net. De library libfam.so kan zo bijvoorbeeld gemakkelijk worden gevonden. Via rpmseek.com kunt u eventueel ook naar Debian pakketten zoeken, maar voor Debian pakketten is packages.debian.org natuurlijk de bron bij uitstek.

categories [