Pakiet libc

libc: ISO 8859.1, <linux/param.h>, funkcje YP (?), kryptograficzne, kilka podstawowych procedur shadow (domyślnie nie włączone), ... stare procedury (dla kompatybilności) są w libcompat (domyślnie wyłączone), angielskie, francuskie oraz niemieckie komunikaty błędów (obecnie pakiet libc6 posiada znacznie więcej tłumaczeń, przyp. tłum.), procedury obsługi ekranu zgodne z BSD4.4lite znajdują się w libcurses, procedury kompatybilne z BSD w libbsd, obsługa ekranu w libtermcap, zarządzanie bazami danych w libdbm, funkcje matematyczne w libm, wejście do uruchamiania programów w crt0.o ???, informacji o płci bajtu (byte sex) w libieee ??? (czy ktoś może dać jakieś informacje zamiast śmiechu ?), ustawienia przestrzeni użytkownika w libgmon. Chciałbym aby ktoś z twórców pakietu libc napisał ten rozdział. Jedyne co mogę powiedzieć obecnie jest to, że zanosi się na zmianę formatu plików wykonywalnych z a.out na elf (executable and linkable format - wykonywalny i 'łączliwy' format), co również oznacza zmianę w budowaniu bibliotek dzielonych. Obecnie oba formaty (a.out i elf) są obsługiwane.

Większa część pakietu libc jest na licencji GNU Public License, poniekąd niektóre części, jak crt0.o, są na pewnej odmianie licencji copyright. Dla komercyjnych programów oznacza to, że zabrania się statycznego łączenia bibliotek z programem. Jednocześnie dynamicznie łączone programy są również pewnym wyjątkiem, o którym Richard Stallman z FSF powiedział:

[...] Wydaje mi się, że powinniśmy jednoznacznie zezwolić na dystrybucję dynamicznie łączonych programów *bez* towarzystwa bibliotek zakładając, iż binaria (object files), które tworzą program nie są ograniczone zgodnie z sekcją nr 5 [...] Podejmę decyzję zezwalająca na to. Na razie aktualizacja LGPL musi poczekać do czasu kiedy stworzę i sprawdzę nową wersję. (od tłum.: zobacz GPL w.2)

Wywołanie systemowe jest zazwyczaj prośbą do systemu operacyjnego (jądra) aby została wykonana operacja zależna od sprzętu/systemu lub uprzywilejowana. Dla Linuxa 1.2 zadeklarowanych zostało 140 wywołań systemowych. Wywołania takie jak close() zaimplementowane są w libc Linuxa. Taka implementacja często wymaga wywołania makra, które odwołuje się do syscall(). Parametry przekazywane do syscall() to numer wywołania oraz potrzebne argumenty. Aktualne numery wywołania można znaleźć w <linux/unistd.h> podczas gdy <sys/syscall.h> jest aktualizowany wraz z nową libc. Jeżeli pojawiają się nowe wywołania systemowe, które nie są zostały jeszcze zawarte w libc, możesz użyć syscall(). Dla przykładu: aby zamknąć plik można użyć syscall() w ten sposób (nie zalecane):

  #include <syscall.h>
  
  extern int syscall(int, ...);
  
  int my_close(int filedescriptor)
  {
     return syscall(SYS_close, deskryptor_pliku);
  }
  

Na platformie i386 wywołania systemowe mają ograniczoną do 5, oprócz numeru wywołania, liczbę argumentów - ze względu na liczbę rejestrów sprzętowych. Jeżeli używasz Linuxa na innej platformie sprawdź w <asm/unistd.h> makro _syscall aby poznać ile argumentów wspomaga twój sprzęt lub ile zostało zdefiniowanych do użycia przez twórców. Makra _syscall mogą być używane zamiast syscall(), jednakże nie jest to zalecane ponieważ takie makro zostanie rozwinięte do funkcji która może już być zdefiniowana w bibliotece. Dlatego tylko specjaliści (kernel hackers) powinni bawić się z makrami _syscall. Dla przykładu: oto close() w postaci makra _syscall.

  #include <linux/unistd.h>
  
  _syscall1(int, close, int, deskryptor_pliku);
  

Makro _syscall1 rozwija się do postaci funkcji close(). Tak więc mamy close() podwójnie - raz w libc i raz w naszym programie. Syscall() lub makro _syscall zwracają -1 jeżeli wywołanie nie powiodło się oraz 0 lub więcej jeżeli udało się. Jeżeli chcesz wiedzieć co dokładnie zawiodło sprawdź wartość zmiennej errno.

Następujące wywołania, które są zdefiniowane w BSD lub SYS V są niedostępne w Linuksie:
audit(), auditon(), auditsvc(), fchroot(), getauid(), getdents(), getmsg(), mincore(), poll(), putmsg(), setaudit(), setauid().