linking runtime libary - statisch oder dynamisch?
-
Was sollte ich beachten, wenn ich gegen die standard runtime Bibliothek (oder wie ist der offizielle Name?) statisch linke?
Sollte man das lieber nicht machen?
Also auf den ersten Blick hat es für mich nur Vorteile:
ich muss die Visual Studio dependencies nicht mit ausliefern und auch keine Weiteren DLLs. Es wird auch nur der Code gelinkt der auch wirklich benötigt wird.Wie ist das mit den mischen dieses Ansatzes?
Also z.B. ich will Lib A in meinem Program nutze, dass die runtime lib dynamisch linkt, kann ich dann trotzdem noch in meinem Program statisch linken oder muss das alles konsistent gegen die runtime lib gelinkt sein?Wie macht ihr das?
-
Nash26 schrieb:
Also auf den ersten Blick hat es für mich nur Vorteile:
ich muss die Visual Studio dependencies nicht mit ausliefern und auch keine Weiteren DLLs. Es wird auch nur der Code gelinkt der auch wirklich benötigt wird.Du profitierst nicht von Sicherheitsupdates und müllst Festplatte und RAM mit redundantem Code zu. Hast du einen bestimmten Grund statisch zu linken?
Nash26 schrieb:
Wie ist das mit den mischen dieses Ansatzes?
Also z.B. ich will Lib A in meinem Program nutze, dass die runtime lib dynamisch linkt, kann ich dann trotzdem noch in meinem Program statisch linken oder muss das alles konsistent gegen die runtime lib gelinkt sein?Ist Lib A eine dll oder eine static library? dll -> kein Problem, static library -> potentiell problematisch
Nash26 schrieb:
Wie macht ihr das?
Ich linke dynamisch, außer ich habe einen ganz speziellen Grund, es nicht zu tun.
-
hab ich doch geschrieben
ich muss die Visual Studio dependencies nicht mit ausliefern und auch keine Weiteren DLLs. Es wird auch nur der Code gelinkt der auch wirklich benötigt wird.
von Festplatte zumüllen kann nicht die rede sein. 2-3Mb mehr sind nix..
Lib A ist eine DLL, also dynamisch.
-
Nash26 schrieb:
von Festplatte zumüllen kann nicht die rede sein. 2-3Mb mehr sind nix..
Und wenn jeder so denkt, dann sind 2-3Mb plötzlich doch nicht nix...
-
schade, gibt es keine dritte Meinung hierzu?
-
Hier gibt es sogar eine offizielle Meinung.
-
Visual Studio 2010 installs Visual C++ libraries as shared DLLs in the %windir%\system32 directory. In order to ensure that your Visual C++ application will run on a computer without Visual C++ installed, you may have to redistribute Visual C++ DLLs with your application and ensure they are installed on the target computer.
Wieso werden die DLLs nicht bei Windows standardmäßig mit installiert?
Das ist halt eines der Hauptgründe warum ich statisch linke.
-
Ich versteh das Problem nicht. Dein Programm kann doch so eine vcredist mitliefern und dann werden die shared installiert.
Ich weiß nicht, ob Windows standardmäßig gar nichts installiert, zumindest kann man aber nicht erwarten, dass die dlls immer auf dem neusten Stand sind.
-
Ich verstehe das Problem. Wenn der Kunde eine einzige "exe" bekommt, wird vieles einfacher. Der Support hat einfach weniger Anfragen diesbezueglich von Kunden. In der Entwicklung wird einmal statisch gelinkt. Problem geloest, waehrend jeder (10te?) Kunde einzeln durch die Installation des Redistributable gefuehrt werden will. Plattenplatz ist auch so eine Sache. Normalerweise soll ja das Redistributable des Entwicklungsstudios mit dem entwickelt wurde mitgeliefert werden. Die Unterscheiden sich, nicht nur nach Version sonder auch nach Updates und Servicepacks. Am Ende hat der Kunde bei mehreren Programmen nicht nur das Redistributable von VS 2005, 2008, 2010 und 2012 auf seinem Rechner sondern auch noch verschiedene Versionen der einzelnen.
