Должен ли я статически или динамически ссылаться на среду исполнения Visual Studio C?

Я прочитал аргументы с обеих сторон о том, следует ли статически или динамически ссылаться на библиотеку времени выполнения C в проектах Visual Studio, и я все еще не совсем уверен, что думать.

Мой проект подключается к некоторым сторонним библиотекам (Python, HDF5, Trilinos и Microsoft MPI), каждый из которых должен быть построен с той же библиотекой времени исполнения, что и мой окончательный исполняемый файл (иначе они не могут быть связаны друг с другом). При связывании статически каждая из этих библиотек будет содержать копию среды выполнения C. Я читал, что это может вызвать проблемы, потому что окончательный исполняемый файл будет содержать несколько копий среды выполнения, ни одна из которых не может взаимодействовать друг с другом. Но не будет ли компоновщик жаловаться на то, что одни и те же символы были бы размножены?

Я бы хотел избежать "DLL Hell", но я беспокоюсь о коварных ошибках, которые могут возникнуть в результате статической привязки в нескольких экземплярах среды выполнения. Я читаю вещи неправильно?

Кроме того, я использую Visual Studio 2005, и я прочитал, что среда выполнения пакета обновления 1 не поддерживает обратную совместимость. Означает ли это, что приложение, построенное без SP1, не будет запущено на машине с пакетом SP1, даже если у них есть одно и то же имя (например, msvcr80.dll)?

Ответ 1

Связывание статически раздувает все ваши EXE и DLL и может вызвать сбои (например, если код в одной DLL вызывает free() с указателем, выделенным malloc() в другой DLL).

Вы можете получить лучшее из обоих миров, связывая динамически и развертывая библиотеки времени исполнения как частные сборки. Это просто означает размещение копии специально названного каталога, содержащего библиотеки времени выполнения и их манифесты рядом с вашим исполняемым файлом.

Подробнее см. раздел "Развертывание библиотек библиотеки Visual С++ в виде приватных ассемблеров" в http://msdn.microsoft.com/en-us/library/ms235291(VS.80).aspx, но в основном ваше приложение выглядит следующим образом:

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

Что касается вашего последнего вопроса, да, целевой машине нужны правильные версии DLL для выполнения, но, развертывая их как частные сборки, вы гарантируете это.

Другим преимуществом является то, что пользователи, не являющиеся администраторами, могут установить ваше приложение (а не в программные файлы, но в других местах) - им не нужно разрешение на запись файлов в область WinSxS.

Ответ 2

Единственный раз, когда вы получите несколько копий среды выполнения, - это когда вы статически связываете библиотеку с DLL - каждая DLL получит копию, а также exe. Если они являются all статическими библиотеками, а не библиотеками DLL, все они свяжутся вместе, и все ваши библиотеки будут использовать одну и ту же среду выполнения.

Это задание компоновщика.

Ответ 3

... Сделать это статически... попытки исправить DLL Hell не так хорошо выработали... просто добавьте дополнительные 200k к вашей установке со статической связью.

Ответ 4

Статические библиотеки не обязательно должны быть статически связаны с другими статическими библиотеками. Вам нужно всего лишь связать все статические библиотеки в вашем основном проекте. Таким образом, компилятор не будет жаловаться на несколько символов.