From: xf0r3m Date: Tue, 23 Apr 2024 17:52:05 +0000 (+0200) Subject: Kontynuowanie tworzenia 14 rozdziału. Podrozdział 14.2 X-Git-Url: https://gitweb.morketsmerke.org/?a=commitdiff_plain;h=24bd4147b65c755f89537e282e0b31f3cf843c09;p=mmdev.git Kontynuowanie tworzenia 14 rozdziału. Podrozdział 14.2 --- diff --git a/articles/terminallog/Linux.Podstawy.html b/articles/terminallog/Linux.Podstawy.html index cc298e5..2c2fc4f 100644 --- a/articles/terminallog/Linux.Podstawy.html +++ b/articles/terminallog/Linux.Podstawy.html @@ -11698,6 +11698,161 @@ ldconfig: Ścieżka `/usr/lib' podana więcej niż raz jej lokalizację (w podrozdziale poniżej, pokazano jak to zrobić).

Konsolidacja programów z bibliotekami współużytkowanymi

+

+ 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. +

+

Problemy związane z bibliotekami współdzielonymi

+

+ 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. +

+

14.1.4. Pliki nagłówkowe

+

+ 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. +

+

Preprocesor języka C

+

+ 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: +

+ +

+ 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. +

+

14.2. Narzędzie make

2024; COPYLEFT; ALL RIGHTS REVERSED;