2010-03-16 15 views
10

Chcę wydać aplikację, którą rozwinąłem jako hobby zarówno dla Linuksa, jak i dla Windows. Ta aplikacja zależy od zwiększenia (i ewentualnie innych bibliotek). Normą dla tego rodzaju aplikacji (silnika szachowego) jest dostarczanie tylko pliku wykonywalnego i ewentualnie niektórych plików pomocniczych.Jakie są zalety i wady statycznego łączenia biblioteki?

Trudno byłoby statycznie połączyć biblioteki, aby plik wykonywalny nie miał żadnych zależności. Zatem użytkownik końcowy może po prostu umieścić plik wykonywalny w katalogu i zacząć go używać.

Jednak podczas przeprowadzania badań w Internecie znalazłem kilka negatywnych komentarzy na temat statycznego łączenia bibliotek, niektóre nawet twierdzą, że aplikacja z statycznie połączonymi bibliotekami byłaby mało przenośna, co oznacza, że ​​działałaby tylko na moim systemie bardzo podobnych systemów.

Jakie są zalety i wady statycznego łączenia biblioteki?

Już wiem, że plik wykonywalny będzie większy. Ale nie widzę powodu, dla którego moja aplikacja byłaby mniej przenośna.

+2

Wiele podróbek, w tym http://stackoverflow.com/questions/140061/when-to-use-dynamic-vs-static-libraries –

+0

@MathieuL Na szybki rzut oka, również http://stackoverflow.com/ pytania/938992/co-są-plus-i-przeciw-używać-a-dll wygląda jak to rozwiązuje pytanie. Może możesz sprawdzić te linki SO i/lub poszukać nieco dalej w SO, i ponownie opublikować z bardziej precyzyjnym pytaniem, czy poprzednie posty nie odpowiadają konkretnym potrzebom. – mjv

Odpowiedz

5

Zalety:
Brak zależności.

Przeciw:
Wyższe zużycie pamięci, ponieważ system operacyjny nie może już używać udostępnionej kopii biblioteki.
Jeśli biblioteka wymaga aktualizacji, aplikacja musi zostać przebudowana. Jest to podwójnie ważne dla bibliotek, które mają następnie poprawki bezpieczeństwa.

Oczywiście większy problem z przenośnością to brak dystrybucji kodu źródłowego.

+0

Cóż, istnieją zależności _are_, chyba że statycznie łączysz wszystko (łącznie z libc), jest to szczególnie prawdziwe w przypadku używania rozszerzeń GNU. –

+0

Być może "brak zależności" należy zmienić na "brak dodatkowych zależności runtime". –

0

Jeśli łączysz biblioteki statycznie, chyba że dodasz inteligentne, aby również sprawdzić system użytkownika dla połączonych bibliotek, blokujesz aplikację, aby korzystać z tych wersji bibliotek, dopóki nie zaktualizujesz pliku wykonywalnego. Pojawiają się dziury w bezpieczeństwie i aktualizacje się zdarzają. (W przypadku silnika szachowego problem może nie być zbyt duży, ale kto wie.)

2

Załóżmy, że dołączona biblioteka statyczna "A" ma zależność od funkcji "B". Jeśli ta zależność nie może być spełniona przez system docelowy, twój program się nie uruchomi.

Ale jeśli korzystasz z dynamicznego łączenia, użytkownik może zainstalować inną wersję biblioteki "A", która używa funkcji "C" zamiast "B", aby mogła działać poprawnie.

+1

CO A *? To kompletny nonsens. Statyczny plik binarny jest w pełni powiązany ze wszystkim, czego potrzebuje. Z tymi nie masz żadnych potrzeb biblioteki. W jaki sposób można przyjąć taką odpowiedź ... – morphles

+1

@morphles: statycznie połączona biblioteka nigdy nie może zawierać * wszystkiego * (w przeciwnym razie musiałaby nawet zawierać jądro ;-) –

0

W przypadku bibliotek połączonych dynamicznie, jeśli biblioteka twierdzi, że X, z którym się łączyłeś, nie jest dostępna w systemie użytkownika, twój kod ulega awarii, co nie pozwala użytkownikowi zastanawiać się.
Podczas gdy w przypadku bibliotek statycznych wszystko jest zespolone z plikiem wykonywalnym, więc warunek taki jak powyżej może się nie zdarzyć, plik wykonywalny będzie jednak bardzo nieporęczny.

Powyższy problem w dynamicznie połączonych bibliotekach może jednak zostać wyeliminowany przez dynamic loading.

Powiązane problemy