Po co tworzyć plik.a z.o jak statyczne linkowanie?

Question

Po co tworzyć plik.a z.o jak statyczne linkowanie?

Rozważ ten kod:

Jeden.c:

#include <stdio.h>

int one() {
   printf("one!\n");
   return 1;
}

Dwa.c:

#include <stdio.h>

int two() {
   printf("two!\n");
   return 2;
}

Prog.c

#include <stdio.h>

int one();
int two();

int main(int argc, char *argv[]) 
{
   one();
   two();

   return 0;
}

Chcę połączyć te programy razem. Więc robię to:

gcc -c -o one.o one.c
gcc -c -o two.o two.c
gcc -o a.out prog.c one.o two.o

To działa dobrze.

Lub mógłbym utworzyć bibliotekę statyczną:

ar rcs libone.a one.o
ar rcs libtwo.a two.o
gcc prog.c libone.a libtwo.a
gcc -L. prog.c -lone -ltwo

Moje pytanie brzmi: dlaczego miałbym używać drugiej wersji-tej, w której stworzyłem".a "pliki-zamiast linkować moje".o " akta? Oba wydają się być statycznie łączone, więc czy istnieje zaleta lub różnica architektoniczna w jednym kontra drugim?

19

linux c gcc static-linking

Author: poundifdef, 2009-12-05

Source

6 answers

Różnica byłaby w wielkości pliku wykonywalnego, chociaż może nie dla Twojego przykładu.

Podczas linkowania do biblioteki włączane są tylko bity używane przez plik wykonywalny. Łącząc plik obiektowy, bierzesz całość.

Na przykład, jeśli Twój plik wykonywalny musi zawierać wszystkie funkcje matematyczne w bibliotece matematycznej, gdy używasz tylko jednej, byłby znacznie większy niż powinien i zawierał dużo nieużywanego kodu.

Warto kontrastować to z dynamicznym modelem łączenia systemu Windows. Tam system operacyjny musi załadować wszystkie biblioteki DLL (dynamicznie połączone biblioteki) w całości, których używa twój program wykonywalny, co może prowadzić do nadęcia w pamięci RAM. Zaletą takiego modelu jest to, że Twój plik wykonywalny jest mniejszy, a połączone biblioteki dll mogą już znajdować się w pamięci używanej przez inny plik wykonywalny, więc nie muszą być ładowane ponownie.

W linkowaniu statycznym funkcje biblioteczne są ładowane oddzielnie dla każdego pliku wykonywalnego.

12

Author: UncleO,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-05 18:34:41

Technicznie wynik jest dokładnie taki sam. Zazwyczaj tworzysz biblioteki dla funkcji użytkowych, więc zamiast podawać linkerowi dziesiątki plików obiektowych, musisz po prostu połączyć bibliotekę.

BTW, absolutnie nie ma sensu tworzyć .plik, który zawiera tylko jeden .plik o.

2

Author: Erich Kitzmueller,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-05 18:10:46

Możesz umieścić zbiór plików w archiwum (.a) plik do późniejszego ponownego wykorzystania. Dobrym przykładem jest biblioteka standardowa.

Czasami warto organizować duże projekty w biblioteki.

2

Author: Richard Pennington,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-05 18:12:04

Podstawową zaletą jest to, że gdy musisz się połączyć, możesz po prostu określić jedną bibliotekę zamiast wszystkich oddzielnych plików obiektowych. Istnieje również niewielka zaleta w zarządzaniu plikami, radzenie sobie z jedną biblioteką zamiast kilkoma plikami obiektowymi. W pewnym momencie dało to również znaczne oszczędności miejsca na dysku, ale obecne ceny dysków twardych sprawiają, że mniej ważne.

1

Author: Jerry Coffin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-05 18:11:31

Ilekroć zadaję sobie to pytanie (przez Świeżaków w moim zespole), "dlaczego (a czasami nawet "co jest") a .a?", Korzystam z poniższej odpowiedzi, która wykorzystujezip jako analogia.

"dotAy jest jak plik zip wszystkich dotOhs, które chcesz połączyć podczas budowania exe / lib. Oszczędność miejsca na dysku, plus nie trzeba wpisywać nazw wszystkich zaangażowanych dotohów."

Do tej pory wydawało im się, że zrozumieją. ;)

0

Author: raghava,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-15 14:33:46

score 38 · Accepted Answer

Zazwyczaj biblioteki są kolekcjami plików obiektowych, które mogą być używane w wielu programach.

W twoim przykładzie nie ma żadnej przewagi, ale mogłeś to zrobić:

ar rcs liboneandtwo.a one.o two.o

Wtedy linkowanie programu staje się prostsze:

gcc -L. prog.c -loneandtwo

To naprawdę kwestia opakowania. Czy masz zestaw plików obiektowych, które naturalnie tworzą zestaw powiązanych funkcji, które mogą być ponownie wykorzystane w wielu programach? Jeśli tak, to można je sensownie zarchiwizować do statycznej biblioteki, w przeciwnym razie tam pewnie nie ma żadnej przewagi.

Jest jedna ważna różnica w końcowym kroku połączenia. Wszystkie połączone pliki obiektów zostaną uwzględnione w końcowym programie. Pliki obiektowe znajdujące się w bibliotekach są dołączane tylko wtedy, gdy pomagają rozwiązywać nieokreślone symbole w innych plikach obiektowych. Jeśli tego nie zrobią, nie zostaną połączone z finalnym plikiem wykonywalnym.