Kontrola domácího úkolu

Na konci minulého dílu jsem zadával domácí úkol, který by čtenáře měl motivovat k používání namespace. Měli jsme vytvořit knihovnu a hlavní program, který ji bude využívat, přičemž oba moduly mají využívat stejně pojmenovanou proměnnou.

Používají se dva typy knihoven: statické, s nimiž se program slinkuje již během kompilace a dynamické (sdílené), kde i na úrovni výsledného spustitelného kódu jsou oba moduly oddělené. U sdílených knihoven pak existují dvě možnosti načtení: rovnou při spuštění a nebo někdy později za běhu. V prvním případě je program na knihovně zcela závislý a bez ní se ani nespustí. V druhém případě je načtení knihovny součástí kódu programu, je třeba také explicitně načíst potřebné symboly knihovny (funkce, globální proměnné), které budeme využívat. Výhodou je, že program není na knihovně tolik závislý, může ji načíst jen někdy a rovněž ošetřit její nedostupnost. Ukážeme si chování programu a knihovny, které mají stejně pojmenovanou proměnnou, a to při všech třech způsobech práce s knihovnou (statická, dynamická načtená při spuštění, dynamická načtená za běhu). Ve všech třech případech bude výsledek odlišný.

Způsob vytváření sdílených knihoven závisí na platformě. Kód uvedený v tomto dílu je určený pro Linux a podobné systémy, nebude proto fungovat například na Windows. Vzhledem k tomu, že problém s konfliktem identifikátorů, na nějž jsem chtěl upozornit, je v C a C++ stejný, zvolil jsem jazyk C.

Hlavní program může vypadat třeba takhle.

/* program.c */
#include <stdio.h>
#include "knihovna.h"

int i = 125;

int main(void) {
  funkceZKnihovny();
  printf("program: i = %i\n", i);
  return 0;
}

Knihovna bude mít dva zdrojové soubory: header

/* knihovna.h */
#ifndef knihovnaH
#define knihovnaH

void funkceZKnihovny(void);
#endif

a vlastní kód.

/* knihovna.c */
#include <stdio.h>
#include "knihovna.h"

int i = 2;

void funkceZKnihovny(void) {
  printf("knihovna: i = %i\n", i);
}

Oba moduly tedy mají globální proměnnou i typu int, která není deklarovaná jako static. V tomto jednoduchém případě je to trochu nelogické, ale pokud by se oba moduly skládaly z většího počtu zdrojových souborů a proměnná i by z nich byla využívána, jako static bychom ji definovat nemohli. V obou modulech je však i chápána jako interní (a nedokumentovaná), nemá tedy tvořit rozhraní. Proto také není uvedena v hlavičkovém souboru knihovny.

Nejprve se pokusíme přeložit projekt jako program se statickou knihovnou.

gcc knihovna.c -c
ar -cr libknihovna.a knihovna.o
gcc program.c -L. -lknihovna -o program

Prvním příkazem jsme přeložili zdrojový kód knihovny do objektového kódu knihovna.o, druhým pak sbalili přeložený kód do knihovny libknihovna.a a konečně třetí příkaz je pokus o přeložení hlavního programu s přilinkovanou knihovnou. Zatím dopadne vše dle očekávání a třetí příkaz neprojde kvůli konfliktu identifikátorů i na úrovni objektového kódu.

./libknihovna.a(knihovna.o):(.data+0x0): multiple definition of `i'
/home/honza/tmp/ccLlnpkA.o:(.data+0x0): first defined here
collect2: ld returned 1 exit status

Není divu, linkování statické knihovny je vlastně jen linkování více objektových souborů a to, že jeden nebo několik z nich jsou zabaleny do knihovny není důležité.

Teď použijeme dynamicky linkovanou knihovnu načtenou při spuštění programu. Zdrojový kód zůstává stejný, liší se jen způsob překladu.

gcc knihovna.c -o libknihovna.so -shared
gcc program.c -L. -lknihovna -o program

Nyní máme přeložený program i sdílenou knihovnu v aktuálním adresáři. Na Linuxu ovšem není aktuální adresář implicitní ani pro spouštěné programy ani pro načítání sdílených knihoven. Pro naše pokusy s knihovnami můžeme implicitní cestu snadno nastavit.

export LD_LIBRARY_PATH=.

Všimněte si, že překlad prošel bez problémů. Možná, že očekáváte chybu při načítání knihovny do paměti po spuštění programu, ale k žádné chybě při dynamickém linkování kupodivu nedojde.

[honza@localhost]$ ./program
knihovna: i = 125
program: i = 125
[honza@localhost]$

Jak je vidět, k chybě došlo později, za běhu. Došlo ke ztotožnění proměnných i, knihovna vypisuje hodnotu z programu. V našem případě to vede pouze k jinému než očekávanému výstupu z programu, podobná situace však může samozřejmě nastat i mezi proměnnými různého typu nebo mezi pointery. V tom případě musíme čekat pád aplikace.

Dynamicky linkovanou knihovnu můžeme načíst i za chodu programu. Podívejme se, zda to bude mít nějaký vliv na náš konflikt identifikátorů. Program je třeba přepsat, neboť v tomto případě je načítání knihovny součástí kódu.

/* program2.c */
#include <dlfcn.h>
#include <stdio.h>

int i = 125;

int main(int argc, char **argv) {
  /* Ukazatel na interní data reprezentující načtenou knihovnu */
  void *pdll;
  /* Ukazatel na funkci z knihovny. */
  void (*funkceZKnihovny)(void);

  /* Za běhu načteme sdílenou knihovnu. */
  pdll = dlopen("./libknihovna.so", RTLD_LAZY);
  if (!pdll) {
    puts(dlerror());
    return 1;
  }
  /* Z knihovny získáme symbol funkceZKnihovny a ukazatel přetypujeme
     na známý prototyp. "*/
  funkceZKnihovny = (void (*)(void)) dlsym(pdll, "funkceZKnihovny");
  if (!funkceZKnihovny) {
    puts(dlerror());
    dlclose(pdll);
    return 2; 
  }
  /* Zavoláme funkci z knihovny. */
  funkceZKnihovny();
  printf("program: i = %i\n", i);
  /* Uvolníme sdílenou knihovnu. */
  dlclose(pdll);
  return 0;
}

Program využívá funkce pro načtení (dlopen) a uvolnění (dlclose) dynamicky linkované knihovny, načtení symbolu z knihovny (dlsym) a text chybové hlášky (dlerror) s poměrně intuitivním způsobem volání, bližší informace najdete v manuálových stránkách.

gcc program2.c -o program2 -ldl

Právě kvůli uvedeným funkcím je třeba linkovat program s knihovnou libdl.so, tj. s parametrem -ldl. Naopak naši knihovnu libknihovna.so si program připojí sám za běhu, tu uvádět nemusíme.

[honza@localhost]$ ./program2
knihovna: i = 2
program: i = 125
[honza@localhost]$

Výstup programu ukazuje, že v případě dynamicky linkované knihovny načtené za běhu k problému nedošlo, globální proměnné i se nepomíchaly.

Závěr

Cílem tohoto dílu nebyl ani tak rychlokurs vytváření knihoven, jako spíš varování před konfliktem identifikátorů. Omezené možnosti jazyků C a C++ a způsob linkování přeloženého kódu mohou způsobit při konfliktu globálních identifikátorů velké a někdy těžko odhalitelné nebo odstranitelné nepříjemnosti. Problémy se navíc mohou lišit systém od systému a (jak jsme si ukázali) závisí i na způsobu spojování modulů. Jediným řešením je podobným problémům předcházet. V C jsme omezeni na volbu vhodných jmen. Všimněte si třeba názvů funkcí GTK+ nebo MySQL C API. To, že názvy funkcí z těchto knihoven začínají na gtk_ respektive mysql_, není jen z důvodu názornosti. Jedná se rovněž o ochranu identifikátorů. V C++ jsme na tom lépe, neboť můžeme používat namespace. Troufl bych si tvrdit, že se jedná o jednu z nejméně doceněných předností C++ oproti C.

Pokračování příště

V příštím dílu povídání o prostorech jmen dokončíme.