Dovrei collegarmi al runtime di Visual Studio C in modo statico o dinamico?

Question

Ho letto argomenti su entrambi i lati sull'opportunità di collegare la libreria di runtime C in modo statico o dinamico nei progetti di Visual Studio e non sono ancora del tutto sicuro di cosa pensare.

Il mio progetto carica alcune librerie di terze parti (Python, HDF5, Trilinos e Microsoft MPI), ognuna delle quali deve essere costruita con la stessa libreria di runtime del mio eseguibile finale (altrimenti non possono essere collegate insieme). Quando si collega staticamente, ciascuna di queste librerie conterrà una copia del runtime C. Ho letto che questo è suscettibile di causare problemi perché l'eseguibile finale conterrà più copie del runtime, nessuno dei quali può interagire tra loro. Ma il linker non si lamenterebbe se gli stessi simboli fossero stati definiti in modo multiplo?

Vorrei evitare "DLL Hell" ma sono preoccupato per errori insidiosi che potrebbero derivare dal collegamento statico in più copie del runtime. Sto leggendo le cose sbagliate?

Inoltre, sto utilizzando Visual Studio 2005 e ho letto che il runtime di Service Pack 1 non è compatibile con le versioni precedenti. Significa che un'app creata senza SP1 non verrà eseguita su un computer con le DLL SP1, anche se hanno lo stesso nome (ad esempio msvcr80.dll)?

Answer 1

Il collegamento statico gonfierà tutti i file EXE e DLL e può causare arresti anomali (ad esempio se il codice in una DLL chiama free() con un puntatore allocato da malloc() in una DLL diversa).

È possibile ottenere il meglio da entrambi i mondi collegando in modo dinamico e distribuendo le DLL di runtime come assembly privati. Ciò significa semplicemente mettere una copia di una directory appositamente denominata contenente le DLL di runtime e i relativi manifest accanto al tuo eseguibile.

vedere la sezione "Distribuzione di Visual C++ DLL biblioteca come assembly privati" a http://msdn.microsoft.com/en-us/library/ms235291(VS.80).aspx per i dettagli, ma fondamentalmente l'applicazione si presenta così:

c:\Program Files\My App\MyApp.exe 
c:\Program Files\My App\MyLibrary.dll 
c:\Program Files\My App\Microsoft.VC80.CRT\Microsoft.VC80.CRT.manifest 
c:\Program Files\My App\Microsoft.VC80.CRT\msvcr80.dll 

Quanto alla tua ultima domanda, sì, la macchina di destinazione ha bisogno del versioni corrette delle DLL di runtime per funzionare, ma distribuendole come assembly privati, lo si garantisce.

Un altro vantaggio è che gli utenti non amministratori possono installare l'app (non in Programmi, ma altrove) - non hanno bisogno dell'autorizzazione per scrivere file nell'area WinSxS.

Answer 2

Le librerie statiche non devono essere collegate in modo statico ad altre librerie statiche. Hai solo bisogno di collegare tutte le librerie statiche nel tuo progetto principale. In questo modo il compilatore non si lamenterà di più simboli.

Answer 3

... Lo fanno staticamente ... i tentativi di risolvere DLL Hell non hanno funzionato bene ... basta aggiungere 200k extra all'installazione con il collegamento statico.

Answer 4

L'unica volta che si ottengono più copie del runtime è quando si collega staticamente una libreria a una DLL - ogni DLL ne riceverà una copia e così anche l'exe. Se sono tutte le librerie statiche e non DLL, si collegheranno tutte insieme e tutte le librerie condivideranno lo stesso runtime.

Questo è il lavoro del linker.