Benutzt irgendwer dynamische Libs?



  • Benutzt hier irgendwer dynamische Bibliotheken (sprich .so oder *.dll)? Falls ja, warum?

    Ich finde das viel praktischer, benötigte Bibliotheken einfach statisch mitzulinken. Klar, die Anwendung wird minimal größer (ist das heute noch ein Argument?!), dafür ist alles in der Anwendung, man muss nicht mehr dafür sorgen das auf anderen Systemen alles konfiguriert ist, der Nutzer kann nicht aus versehen dlls löschen etc. pp ➡ ⚠



  • Ich und häufig.

    Dynamische Libraries können zwischen mehreren Programmen ausgetauscht und dadurch Speicherplatz gespart werden.
    Zudem kann man auch einzelne Libraries neu compilen, ohne das Endprodukt neu linken zu müssen, man kann einzelne Komponenten austauschen und patchen.
    So konnte man z.B. bei Spielen mit der Irrlicht-Engine einfach die dll der Version 1.7.1 durch 1.7.2 ersetzen und hatte ein paar Bugfixes mehr, obwohl der Programmierer das Spiel noch nicht aktualisiert hat.

    Zudem können sie dynamisch geladen werden, z.B. als Plugin, und man kann sie teilweise von anderen Programmiersprachen (z.B. AutoIt) nutzen.


  • Mod

    Ich. Praktisch immer. Argumente dafür: Die offensichtlichen Gründe, wegen denen dynamische Libs so weit verbreitet sind (und die von Marthog nochmal genannt wurden und ansonsten auch auf Wikipedia stehen).

    Statisch linke ich nur ganz selten. Wir hatten mal so ein paar Rechner im Rechencluster, die waren nicht richtig konfiguriert. Da habe ich dann statisch gelinkt.



  • Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x und C++11) in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Ich linke alles statisch was ich kann, Speicherplatz in der Größenordnung interessiert mich nicht. (Vielleicht würde ich daran etwas ändern, wenn meine .exe Dateien größer würden als 10MB. Das ist aber fast nie der Fall, wenn man nur ein bisschen am Frickeln ist.)



  • Ja, ich auch! Neben den schon genannten Gründen: Was nicht ständig gebraucht wird, wird nur bei Bedarf dymamisch angefordert und schnellstmöglich wieder freigegeben.



  • cooky451 schrieb:

    (Vielleicht würde ich daran etwas ändern, wenn meine .exe Dateien größer würden als 10MB.

    Dann wären unsere .exe Dateien mehrere hundert MB groß. Wenn wir auch noch 3rdparty Bibliotheken statisch reinlinken würden, nochmal ein Stück größer.
    Außerdem haben wir etliche unterschiedliche .exe Dateien, die dieselben Bibliotheken verwenden, macht doch keinen Sinn, alles statisch reinzulinken, damit am Ende 50 Programme mit jeweils zig hundert MB Größe rauskommen. Und wenn dann tatsächlich mehrere davon gleichzeitig laufen, muss man den gemeinsamen Code auch nicht mehrfach laden.



  • Also ich linke alles dynamisch, Ausnahmen: Wenn ich ein kleines Programm nur kurz testweise linke (< 100 Zeilen)...
    Aber sonst alles dynamisch...Die Vorteile wurde ja schon alle genannt (schnelleres Austauschen etc.) und vor allem bewege ich mich meist in der Linux Welt und hier ist alles dynamisch gelinkt (/usr/lib/) 😉
    Und ein weiterer Grund: einige von mir benutzte Libs dürfen nur so gelinkt werden (z.B. QT)...
    MfG



  • Um ehrlich zu sein, nerven mich diese Shared-Libs unter Linux.

    Mag sein, dass es einen Platzspar-vorteil gibt, wenn verschiedene Programme die gleichen Libs nutzen, aber ich finde es mehr als unnötig, dass ich mir bei manchen Programmen mehrere Shared-Libs mitladen muss, weil sonst das Programm nicht funktioniert.



  • Naja stören tut das ja wohl kaum, die meisten Pakete installiere ich über meinen Paketemanager (YaST) da interessiert es mich nicht wie viele Pakete nebenbei geladen werden, Aufwand ist der selbe.
    Und der Vorteil ist einfach, das ich bei z.B. einem Bugfix von einem Paket (z.B. QT) nicht gleich alle Programme updaten muss (was bei statisch gelinkten sehr große Datenmengen dann wären je nach Programm) sondern nur die Libs updaten muss...
    Und mit max. 150KB/s macht es nicht so Bock 100 Programme updaten zu müssen 😉

    MfG



  • Wir (Firma) verwenden viele DLLs.

    Hauptsächlich weil die Linkzeiten dadurch sinken und natürlich auch weil die Binaries dadurch tendenziell kleiner werden (kann manchmal auch umgekehrt sein, z.B. wenn man nur einen kleinen Teil einer grossen LIB braucht, und das nur in einem Projekt gewinnt normalerweise die LIB).



  • Ich frage mich immer, warum manche Anwendungen unter Windows, vor allem Spiele, so viele DLL-Dateien haben.

    Wie ja in diesem Thread schon angesprochen wurde, eigentlich sollten diese DLLs/SOs einen Vorteil bringen, indem sich mehrere Programme die gleichen Dateien "teilen" (-> "Shared").

    Wenn aber eine Anwendung sozusagen ihre eigenen DLLs hat, also DLLs, die nur diese Anwendung braucht, wie es ja bei Spielen so ist, dann untergräbt das den einzig vernünftigen Grund für DLLs.

    Hat die Dateigröße einer exe etwas mit ihrer Ausführungsgeschwindigkeit zu tun? Ich weiß es nicht.


  • Mod

    dlls unter windows schrieb:

    Hat die Dateigröße einer exe etwas mit ihrer Ausführungsgeschwindigkeit zu tun?

    Nein.

    Ich weiß es nicht.

    Jetzt schon. 😃



  • Reine Vermutung aber vielleicht wird das gemacht weil dann nur die gerade wirklich benötigten Bibliotheken zur Laufzeit in den Speicher geladen werden müssen... Daher nicht die komplette Datei in den Speicher geladen werden muss...
    MfG



  • Das kommt der Sache recht nah. Aber es gibt auch Leute, die am Auto ständig den Skiträger mit Gepäckbox befestigt haben und natürlich stets den Anhänger mitführen, weil sie mal zum Baumarkt wollen. 🙂



  • berniebutt schrieb:

    Das kommt der Sache recht nah. Aber es gibt auch Leute, die am Auto ständig den Skiträger mit Gepäckbox befestigt haben und natürlich stets den Anhänger mitführen, weil sie mal zum Baumarkt wollen. 🙂

    naja.
    ffmpeg beipielsweise unter windows eine einzige executable, ca. 20MB groß.

    den anwender kümmert es nicht.



  • derFer schrieb:

    .Die Vorteile wurde ja schon alle genannt (schnelleres Austauschen etc.)

    Nein, wurden sie nicht.

    Dazu kommen noch:

    - mit dynamischen Libs ist das System schneller. Wenn sich 10 Anwendungen die gleiche Lib teilen und eine Anwendung die Lib schon in den Speicher geladen hat, dann ist der Start der restlichen 9 Anwendungen wesentlich schneller, als wenn diese 9 Anwendungen die Lib statisch reingelinkt hätte.
    Denn bei den darauffolgenden Starts muss die Lib nicht mehr erst geladen werden, da sie schon geladen ist.
    Dynamisch zu linken hilft also der Performance und Reaktionszeit des Gesamtsystems.

    - bei manchen Bibliotheken MUSS man, wenn man das Endprodukt weitergibt, aufgrund der Lizenz unter der sie vertrieben werden, dynamisch Linken. Als Beispiel wären da z.B. alle Bibliotheken zu nennen, die die LGPL als Lizenz verwenden.



  • dlls unter windows schrieb:

    Ich frage mich immer, warum manche Anwendungen unter Windows, vor allem Spiele, so viele DLL-Dateien haben.

    Wie ja in diesem Thread schon angesprochen wurde, eigentlich sollten diese DLLs/SOs einen Vorteil bringen, indem sich mehrere Programme die gleichen Dateien "teilen" (-> "Shared").

    Wenn aber eine Anwendung sozusagen ihre eigenen DLLs hat, also DLLs, die nur diese Anwendung braucht, wie es ja bei Spielen so ist, dann untergräbt das den einzig vernünftigen Grund für DLLs.

    Hat die Dateigröße einer exe etwas mit ihrer Ausführungsgeschwindigkeit zu tun? Ich weiß es nicht.

    Klar, umso größer die EXE, desto länger dauert es diese zu Laden.
    Das merkt man auf SSDs meist nicht mehr, aber bei fetten Librarys die statisch in die EXE gelinkt werden, können das schon Sekunden auf HDs betragen.

    Und Spiele haben oft DLLs, weil es die Lizenzen so vorschreiben.



  • Es ist ja nicht so das die ganze EXE beim Start direkt komplett von der Festplatte geladen wird. Es wird immer nur das geladen was benötigt wird.



  • Dynamisch Linken rulez schrieb:

    Klar, umso größer die EXE, desto länger dauert es diese zu Laden.
    Das merkt man auf SSDs meist nicht mehr, aber bei fetten Librarys die statisch in die EXE gelinkt werden, können das schon Sekunden auf HDs betragen.

    Falsch.
    Die EXE wird beim "Laden" nicht komplett geladen, sondern es wird bloss das PE Image in den Speicher gemappt.
    Geladen wird dann nur das was benötigt wird.
    Und eine fette EXE verglichen mit einer EXE + ein paar DLLs (die in Summe dann ca. gleich gross oder sogar grösser sind), da gewinnt klar die monolithische EXE.

    Weil da wenigstens nur ein File geladen werden muss vs. mehrere Files bei EXE + DLLs. D.h. weniger Suchzeiten.

    Und für "mehrere Sekunden bei HDs" müsste die EXE schon mehrere hundert MB gross sein.


Log in to reply