Unterschied zwischen statischen und gemeinsam genutzten Bibliotheken?

560

Was ist der Unterschied zwischen statischen und gemeinsam genutzten Bibliotheken?

Ich verwende Eclipse und es gibt verschiedene Projekttypen, einschließlich statischer Bibliotheken und gemeinsam genutzter Bibliotheken. Hat einer einen Vorteil gegenüber dem anderen?

c++ c shared-libraries static-libraries

— Mohit Deshpande
quelle

4

Wikipedia bietet eine gute Beschreibung der Unterscheidung zwischen statischen, dynamischen und gemeinsam genutzten Bibliotheken.

— Adam Holmberg

745

Freigegebene Bibliotheken sind .so-Dateien (oder in Windows-DLL- oder OS X-DLL-Dateien). Der gesamte Code für die Bibliothek befindet sich in dieser Datei und wird von Programmen, die ihn zur Laufzeit verwenden, referenziert. Ein Programm, das eine gemeinsam genutzte Bibliothek verwendet, verweist nur auf den Code, den es in der gemeinsam genutzten Bibliothek verwendet.

Statische Bibliotheken sind .a-Dateien (oder in Windows-LIB-Dateien). Der gesamte Code für die Bibliothek befindet sich in dieser Datei und ist zur Kompilierungszeit direkt mit dem Programm verknüpft. Ein Programm, das eine statische Bibliothek verwendet, nimmt Kopien des verwendeten Codes aus der statischen Bibliothek und macht ihn Teil des Programms. [Windows verfügt auch über LIB-Dateien, mit denen auf DLL-Dateien verwiesen wird, die sich jedoch genauso verhalten wie die erste].

Jede Methode hat Vor- und Nachteile:

Freigegebene Bibliotheken reduzieren die Menge an Code, die in jedem Programm, das die Bibliothek verwendet, dupliziert wird, und halten die Binärdateien klein. Sie können das gemeinsam genutzte Objekt auch durch ein Objekt ersetzen, das funktional gleichwertig ist, jedoch möglicherweise zusätzliche Leistungsvorteile bietet, ohne das Programm, das es verwendet, neu kompilieren zu müssen. Für gemeinsam genutzte Bibliotheken fallen jedoch geringe zusätzliche Kosten für die Ausführung der Funktionen sowie Kosten für das Laden zur Laufzeit an, da alle Symbole in der Bibliothek mit den von ihnen verwendeten Elementen verbunden werden müssen. Darüber hinaus können gemeinsam genutzte Bibliotheken zur Laufzeit in eine Anwendung geladen werden. Dies ist der allgemeine Mechanismus zum Implementieren von binären Plug-In-Systemen.
Statische Bibliotheken erhöhen die Gesamtgröße der Binärdatei, bedeuten jedoch, dass Sie keine Kopie der verwendeten Bibliothek mitnehmen müssen. Da der Code zur Kompilierungszeit verbunden ist, fallen keine zusätzlichen Ladekosten zur Laufzeit an. Der Code ist einfach da.

Persönlich bevorzuge ich gemeinsam genutzte Bibliotheken, verwende jedoch statische Bibliotheken, wenn sichergestellt werden soll, dass die Binärdatei nicht viele externe Abhängigkeiten aufweist, die möglicherweise schwer zu erfüllen sind, z. B. bestimmte Versionen der C ++ - Standardbibliothek oder bestimmte Versionen der Boost C ++ - Bibliothek.

— Petesh
quelle

2

"Ersetzen Sie das gemeinsam genutzte Objekt durch ... funktional äquivalent, kann aber die Leistung [verbessern]": Insbesondere äquivalente Funktionalität für Aufrufer bei der semantischen Verwendung der API (Anwendungsprogrammierschnittstelle: Funktionssignaturen und Variablen einschließlich Typen), jedoch implementierungsseitig Die Funktionalität kann sich in mehr als der folgenden Leistung unterscheiden: z. B. protokolliert die Funktion immer in der Datei -> auch im TCP-Server: Port wird in $ MY_APP_LOG_SERVER erwartet.

— Tony Delroy

1

"[.sos verursachen] geringe zusätzliche Kosten für die Ausführung der Funktionen" - das ist möglich (wenn Funktionsgruppen / Reihenfolge für die Cache-Lokalität in der statischen Verknüpfung optimiert wurden oder aufgrund von Kuriositäten in Betriebssystem / Loader / Compiler / Architektur wie cross -segment / große Zeiger perf. Strafen), aber auf vielen Architekturen / Compiler-Einstellungen patcht der dynamische Linker den Aufruf, um genau die gleichen Opcodes der aufrufenden Maschine zu erstellen.

— Tony Delroy

2

"Da der Code zur Kompilierungszeit verbunden ist, fallen keine zusätzlichen Kosten für das Laden zur Laufzeit an. Der Code ist einfach da." - Ja und Nein ... alles im ausführbaren Image kann bei Bedarf ausgelagert werden, aber - ausgehend von einer Situation, in der Ihr Programm in letzter Zeit nicht genug ausgeführt wurde, um sich im Cache zu befinden - ist es mit gemeinsam genutzten Bibliotheken möglich (manchmal wahrscheinlich) oder sicher), dass das Betriebssystem, ein Treiber oder ein anderes laufendes Programm bereits dieselbe gemeinsam genutzte Bibliothek geladen hat, die Ihre App verwenden möchte. In diesem Fall befindet sie sich möglicherweise im Cache und Ihr Programm wird schneller gestartet und ausgeführt.

— Tony Delroy

15

Was einige Leute nicht erwähnt haben, ist, dass der Compiler bei statischen Bibliotheken weiß, welche Funktionen Ihre Anwendung benötigt, und diese dann optimieren kann, indem er nur diese Funktionen einbezieht. Dies kann die Bibliotheksgröße massiv reduzieren, insbesondere wenn Sie nur eine wirklich kleine Teilmenge einer wirklich großen Bibliothek verwenden!

— JDUNcanator

1

Diese Antwort könnte besser organisiert sein. Es wäre hilfreich, Aufzählungslisten für Vor- / Nachteile oder eine Tabelle zu erstellen, um die Unterschiede in jeder Dimension anzuzeigen, in der es Unterschiede gibt.

— ElefEnt

377

Eine statische Bibliothek ist wie eine Buchhandlung, und eine gemeinsam genutzte Bibliothek ist wie ... eine Bibliothek. Mit dem ersteren erhalten Sie Ihre eigene Kopie des Buches / der Funktion zum Mitnehmen; Mit letzterem gehen Sie und alle anderen in die Bibliothek, um dasselbe Buch / dieselbe Funktion zu verwenden. Jeder, der die (gemeinsam genutzte) Bibliothek nutzen möchte, muss wissen, wo sie sich befindet, da Sie das Buch / die Funktion "holen" müssen. Mit einer statischen Bibliothek gehört das Buch / die Funktion Ihnen, und Sie behalten es in Ihrem Heim / Programm, und sobald Sie es haben, ist es Ihnen egal, wo oder wann Sie es haben.

— Paul Richter
quelle

70

Vereinfacht:

Statische Verknüpfung: eine große ausführbare Datei
Dynamische Verknüpfung: Eine kleine ausführbare Datei plus eine oder mehrere Bibliotheksdateien (DLL-Dateien unter Windows, SO unter Linux oder DLLIB unter MacOS)

— StackedCrooked
quelle

1

Diese Antwort ist die beste für mich, weil sie praktisch ist. Es ist viel sinnvoller als eine Metapher, die nicht darüber spricht, was tatsächlich im Computer passiert. Nachdem ich weiß, dass dies der Fall ist, kenne ich alle anderen Implikationen intuitiv.

— off99555

36

Bei einer statischen Bibliothek wird der Code vom Linker aus der Bibliothek extrahiert und zum Erstellen der endgültigen ausführbaren Datei an dem Punkt verwendet, an dem Sie Ihre Anwendung kompilieren / erstellen. Die endgültige ausführbare Datei hat zur Laufzeit keine Abhängigkeiten von der Bibliothek

Bei einer gemeinsam genutzten Bibliothek überprüft der Compiler / Linker, ob die Namen, mit denen Sie verknüpfen, in der Bibliothek vorhanden sind, wenn die Anwendung erstellt wird, verschiebt jedoch ihren Code nicht in die Anwendung. Zur Laufzeit muss die gemeinsam genutzte Bibliothek verfügbar sein.

Die Programmiersprache C selbst hat weder ein Konzept für statische noch für gemeinsam genutzte Bibliotheken - sie sind vollständig eine Implementierungsfunktion.

Ich persönlich bevorzuge die Verwendung statischer Bibliotheken, da dies die Softwareverteilung vereinfacht. Dies ist jedoch eine Meinung, über die in der Vergangenheit viel (bildliches) Blut vergossen wurde.

5

+1 für "Die Programmiersprache C selbst hat weder ein Konzept für statische noch für gemeinsam genutzte Bibliotheken - sie sind vollständig eine Implementierungsfunktion."

— Tiger

1

Hallo anon / @Tiger, warum haben Sie gesagt: "Die Programmiersprache C selbst hat kein Konzept für statische oder gemeinsam genutzte Bibliotheken - sie sind vollständig eine Implementierungsfunktion." Können Sie mir bitte etwas näher erläutern oder mich auf eine entsprechende Referenz verweisen?

— Sunil Shahu

@SunilShahu Wie das Programm kompiliert und verknüpft wird, hängt vom verwendeten Compiler und Linker ab, dh von der spezifischen Implementierung der Sprache. Sprachspezifikationen beschreiben im Allgemeinen nicht, wie Sprachen implementiert oder erstellt werden sollen, sondern nur die Funktionalität, Syntax, Grammatik usw.

— JC Rocamonde

@SunilShahu offensichtlichere Beispiele könnten beispielsweise JavaScript sein, bei dem die Spezifikation (EcmaScript) die Merkmale der Sprache beschreibt, aber es sind die verschiedenen Anbieter, die die JS-Interpreter ausliefern (z. B. Browser-Engines oder Node.js). Andererseits hat die Programmiersprache Python mehrere Implementierungen. Das offizielle ist CPython, aber es gibt andere, die in anderen Sprachen geschrieben sind.

— JC Rocamonde

31

Statische Bibliotheken werden als Teil einer Anwendung kompiliert, gemeinsam genutzte Bibliotheken hingegen nicht. Wenn Sie eine Anwendung verteilen, die von gemeinsam genutzten Bibliotheken abhängt, werden die Bibliotheken, z. DLLs unter MS Windows müssen installiert sein.

Der Vorteil statischer Bibliotheken besteht darin, dass für den Benutzer, der die Anwendung ausführt, keine Abhängigkeiten erforderlich sind - z. B. müssen sie ihre DLL nicht aktualisieren. Der Nachteil ist, dass Ihre Anwendung größer ist, da Sie sie mit allen benötigten Bibliotheken ausliefern.

Gemeinsame Bibliotheken führen nicht nur zu kleineren Anwendungen, sondern bieten dem Benutzer auch die Möglichkeit, ihre eigene, möglicherweise bessere Version der Bibliotheken zu verwenden, anstatt sich auf eine zu verlassen, die Teil der Anwendung ist

— Tarski
quelle

3

DLL Hölle wie es bekannt ist

— Gheese

1

"Statische Bibliotheken werden als Teil einer Anwendung kompiliert" ... statische Bibliotheken werden als statische Bibliotheken kompiliert und als Teil einer Anwendung verknüpft

— idclev 463035818

19

Der wichtigste Vorteil von gemeinsam genutzten Bibliotheken besteht darin, dass nur eine Kopie des Codes im Speicher geladen ist, unabhängig davon, wie viele Prozesse die Bibliothek verwenden. Bei statischen Bibliotheken erhält jeder Prozess eine eigene Kopie des Codes. Dies kann zu einer erheblichen Speicherverschwendung führen.

OTOH, ein Vorteil statischer Bibliotheken ist, dass alles in Ihrer Anwendung gebündelt ist. Sie müssen sich also keine Sorgen machen, dass der Client über die richtige Bibliothek (und Version) auf seinem System verfügt.

— Jasmeet
quelle

1

Das ausführbare Image ist sowohl auf der Festplatte als auch im Speicher größer, wenn statische Bibliotheken verwendet werden.

— JustJeff

Das ist richtig, darauf habe ich angespielt, als ich sagte, dass alles in Ihrer Anwendung gebündelt ist.

— Jasmeet

Außerdem sind .soDateien auf * nix-Systemen eine Art gemeinsam genutzte (dynamische) Bibliothek.

— Snr

6

Neben all den anderen Antworten ist eine Entkopplung noch nicht erwähnt:

Lassen Sie mich über einen realen Produktionscode sprechen, mit dem ich mich befasst habe:

Eine sehr große Software, die aus> 300 Projekten (mit Visual Studio) besteht, meistens als statische Bibliothek erstellt wird und schließlich alle in einer riesigen ausführbaren Datei miteinander verbunden sind, führt zu folgenden Problemen:

-Link-Zeit ist extrem lang. Möglicherweise benötigen Sie mehr als 15 Minuten Link, z. B. 10 Sekunden Kompilierungszeit. Einige Tools sind mit einer so großen ausführbaren Datei auf dem Knie, wie z. B. Tools zur Speicherprüfung, die den Code instrumentieren müssen. Sie könnten an Grenzen stoßen, die als Dummköpfe angesehen wurden.

Problematischer ist die Entkopplung Ihrer Software: In diesem Beispiel aus der Praxis waren Header-Dateien jedes Projekts von allen anderen Projekten aus erreichbar. Infolgedessen war es für einen Entwickler äußerst einfach, Abhängigkeiten hinzuzufügen. Es ging nur darum, den Header einzuschließen, da der Link am Ende immer Symbole findet. Es endet mit schrecklichen Fahrradabhängigkeiten und völligem Durcheinander.

Bei einer gemeinsam genutzten Bibliothek ist dies ein wenig zusätzlicher Aufwand, da der Entwickler das Projekterstellungssystem bearbeiten muss, um die abhängige Bibliothek hinzuzufügen. Ich habe festgestellt, dass gemeinsam genutzter Bibliothekscode tendenziell eine sauberere Code-API bietet.

— Sandholz
quelle

2

-------------------------------------------------------------------------
|  +-  |    Shared(dynamic)       |   Static Library (Linkages)         |
-------------------------------------------------------------------------
|Pros: | less memory use          |   an executable, using own libraries|
|      |                          |     ,coming with the program,       |
|      |                          |   doesn't need to worry about its   |
|      |                          |   compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of       |   bigger memory uses                |
|      | libraries may be altered |                                     |
|      | subject to OS  and its   |                                     |
|      | version, which may affect|                                     |
|      | the compilebility and    |                                     |
|      | runnability of the code  |                                     |
-------------------------------------------------------------------------

— snr
quelle