From 24bd4147b65c755f89537e282e0b31f3cf843c09 Mon Sep 17 00:00:00 2001
From: xf0r3m
+ JeÅli w kompilowanym programie używaliÅmy jakiÅ niestandardowych + bibliotek wspóÅużytkowanych, których próżno szukaÄ w zasobach + systemowych musimy podczas konsolidacji wskazaÄ scieżkÄ oraz nazwÄ + biblioteki podczas uruchamiania kompilatora (tak jak robiliÅmy to + wczeÅniej - w przypadku bibliotek statycznych). Tutaj niezbÄdne + bÄdzie również wskazanie katalogu w celu dodania go do Åcieżki + wyszukiwania bibliotek. W tego typu przypadkach nie należy posÅugiwaÄ + siÄ ustawieniemi konsolidatora dynamicznego. +
+ + Opcja, o której mowa to:-Wl,-rpath.
+ PrzykÅad poniżej może to zobrazowaÄ:
+
++xf0r3m@laptop-5cfe659:~$ cc -o myprog myprog.o -Wl,rpath=/opt/pt/lib -L/opt/pt/lib -lnetstats ++
+ DomyÅlny standardem dla plików wykonywalnych oraz bibliotek w + dystrybucjach Linuksa jest ELF - Executable and + Linkable Format, dziÄki czemu możemy zmieniÄ ÅcieżkÄ + wyszukiwania bibliotek dla Årodowiska wykonawczego. Możemy tego + dokonaÄ za pomocÄ polecenia patchelf. +
++ NajczÄÅciej wystÄpujÄ cym problemem zwiÄ zanym z bibliotekami + wspóÅdzielonymi jest ich potencjalny brak w naszym systemie. Wówczas + musimy szukaÄ pakietów z koÅcówkÄ -dev w nazwie i + zeÅmiecaÄ system gigabajtami niepotrzebnych plików. +
+
+ KolejnÄ
rzeczÄ
może byÄ, za dÅuga wartoÅÄ zmiennej
+ LD_LIBRARY_PATH. ZawartoÅÄ tej
+ zmiennej jest odczytywana przez konsolidator, który nastÄpnie
+ przeszukuje podane Åcieżki pod kÄ
tem wystÄpowania bibliotek. Ta
+ zmianna ma pierwszeÅstwo przez pozostaÅymi lokalizacjami, w których
+ mogÄ
wystÄ
piÄ biblioteki w systemie. Dlatego też ustawienie jej
+ globalnie gdzieÅ w systemie (np. w plikach konfiguracyjnych powÅoki)
+ może spowodowaÄ znaczy spadek wydajnoÅci systemu. JeÅli już musimy
+ wskazaÄ innÄ
lokalizacjÄ bibliotek dla programów a nie chcemy
+ ponownie kompilowaÄ (lub nie mamy takiej możliwoÅci, brak kodu
+ źródÅowego), możemy utworzyÄ tzw. skrypt opakowywujÄ
cy -
+ manipulujÄ
cy zawartoÅciÄ
zmiennej
+ LD_LIBRARY_PATH oraz uruchamiajÄ
cy
+ żÄ
dany program. Przy czym zmienna zostanie zmieniona wyÅÄ
cznie
+ w obrÄbie procesu podpowÅoki uruchomionego na potrzeby skryptu
+ (WiÄcej o skryptach znajduje siÄ w dodatku A).
+
+ Nie mniej jednak najlepszÄ ucieczkÄ przez problemami zwiÄ zanymi z + bibliotekami jest ich wskazanie w procesie konsolidacji lub użycie + bibliotek statycznych. +
+
+ Aby programiÅci mogi skorzystaÄ z bibliotek w swoich programach muszÄ
+ siÄ do nich w jakiÅ sposób odwoÅaÄ. W jÄzyku C mogÄ
wykorzystaÄ do
+ tego pliki nagÅówkowe zawierajÄ
cy deklaracje typów
+ oraz funkcji bibliotecznych. Jednym z takich plików, byŠstdio.h
+ przedstawiany we wczeÅniejszych przykÅadach - ten plik nagÅówkowy
+ udostÄpniaÅ nam funkcjÄ printf().
+
+ Do wskazywania plików nagÅówkowych sÅuży dyrektywa
+ #include. Czasami zdarza siÄ, że
+ programiÅci dodajÄ
omyÅkowo jakiÅ plik nagÅówkowy, który nie
+ istnieje. Tego typu bÅÄdy zostajÄ
wyÅapane już na poziomie kompilacji
+ gdzie kod jest wstÄpnie analizowany.
+
+ OczywiÅcie, może tak byÄ, że wykorzystywane przez programistów + pliki nagÅówkowe nie znajdujÄ siÄ w standardowej lokalizacji dla + tego rozdzaju plików w systemie (/usr/include). JeÅli tak + jest to, możemy skorzystaÄ z opcji kompliatora pozwalajÄ cÄ dodaÄ + podany katalog do Åcieżki wyszukiwania plików nagÅówkowych. +
++xf0r3m@laptop-5cfe659:~$ cc -c -I/opt/pt/include netstats.c ++
+ IstniejÄ dwie metody na doÅÄ czenie plików nagÅówkowych do kodu + programu. Różnice te sÄ doÅÄ subtelne jednak majÄ doÅÄ duże + znaczenie. +
++#include <stdio.h> ++
+ Klasyczne doÅÄ czenie pliku nagÅówkowego. Mówi on nam, że kompilator + bÄdzie przeszukiwaÄ zasoby systemowego, aby użyÄ tego pliku na + potrzeby kompilacji. +
++#include "ip.h" ++
+ Użycie podwójnych apostrofofów zamiast ostych nawiasów, spowoduje że + kompilator przeszuka katalog z podanym kodem źródÅowym w poszukiwaniu + tak zaÅÄ czonego pliku nagÅówkowego. Tak zaÅÄ czone pliki nagÅówkowe + muszÄ wystÄpowaÄ w tym samym folderze do kompilowany kod źródÅowy. + Jest to przydatne w przypadku, gdy korzystamy z wÅasnych plików tego + rodzaju. +
++ WczeÅnie mówiliÅmy o kompilatorze w kontekÅcie odnajdywania plików + nagÅówkowych, jednak nie jest do dokoÅca prawdÄ . Preprocesor w + przypadku jÄzyka C, zajmuje siÄ dostoswaniem kodu pisanego przez + czÅowiek dla kompilatora. Wykonuje on swoje dziaÅania na podstawie + dyrektyw zapisywanych przez ludzi w kodzie dodajÄ c + do niego kilka uproszczeÅ oraz skrótów. +
+
+ Dyrektywy to nic innego jak instrukcje. Jednak, aby odróżniaÅy siÄ
+ do instrukcji wÅaÅciwego jÄzyka w C, poprzedza siÄ znakiem
+ krzyżyka (#). TakÄ
dyrektywÄ poznaliÅmy już, a jest
+ niÄ
dyrektywa #include. W jÄzyku C
+ dostÄpne sÄ
trzy rodzaje dyrektyw:
+
+#define PI 3.14 ++
+ Istotnym czynnikiem w wykorzystaniu makr a co za tym idzie kompilacji + warunkowej jest możliwoÅÄ przekazania makra do preprocesora za pomocÄ + opcji -D kompilatora. Taka możliwoÅÄ interakcji, na pewno + bardziej wyjaÅnia sens istnienia dyrektyw oraz samego preprocesora. +
++ OdnoÅnie samego preprocesora, to nie zna on żadnych elementów jÄzyka + C. Jest on skupiony wyÅÄ cznie na makrach oraz pozostaÅych dyrektywach. +
+2024; COPYLEFT; ALL RIGHTS REVERSED; -- 2.39.5