Динамическое и статическое связывание и развертывание в Visual Studio 2010

У меня неуправляемый проект на C++ в Visual Studio 2010. Он использует boost, glut и другую библиотеку от поставщика.Динамическое и статическое связывание и развертывание в Visual Studio 2010

Я создал проект, чтобы создать более "dll-indepenendent" исполняемый файл. Все библиотеки ускорения связаны статически, и нет необходимости в dll в каталоге, где исполняемый файл остается.

То же самое для Glut, я связал статический glut32.lib вместо glut32.dll и снова не проблема.

Я выбрал для библиотек времени выполнения версию NON-DLL, то есть многопоточную отладку (для конфигурации отладки) и конфигурацию Multithreaded for Release.

Теперь продавец, о котором я говорил раньше, предоставляет две альтернативы Vendor.lib и Vendor.dll.

Vendor.lib добавлен в Linker-> Дополнительные зависимости, но во время выполнения мне всегда нужно поместить файл Vendor.dll в тот же каталог исполняемого файла, иначе среда выполнения жалуется, потому что не находит поставщика .dll.

Как решить эту проблему? Я бы хотел, чтобы не помещать в каждый каталог DLL-файл.

Я не хочу помещать dll в ту же директорию exe и вообще какие руководящие принципы для развертывания неуправляемых консольных приложений C++ в Visual Studio?

Я знаю, что есть много вопросов и страниц об этом аргументе, но ни один из них не уточнил мне этот момент.

Некоторые идеи?

источник

2012-03-05 linello

Microsoft немного забавна в том, как она справляется с этим: при создании файла .dll вы также создаете .lib, который содержит общедоступные символы в файле .dll. Вы должны ссылаться на .lib, чтобы загрузить DLL с во время выполнения, но этот .lib по-прежнему не является статической библиотекой. Если ваш поставщик предоставляет версию для статического связывания, то либо будет .dll, либо два .lib (предположительно, в разных каталогах или с разными именами). Еще один пример Microsoft, делающий серьезную разработку более сложно, чем необходимо.

источник

2012-03-05 13:52:00

Это не зависит от MS. В Linux также есть библиотеки импорта. – rubenvb

Unix имеет два типа «библиотек»: библиотеки (файлы .a) и общие объекты (файлы .so).Поставщик, предоставляющий библиотеку (в общем смысле), обычно предоставляет оба. Если вы ссылаетесь на файл .a, вы ставите ссылку, и если вы ссылаетесь на .so, вы связываете динамически. Проблема с решением Microsoft заключается в том, что 1) у вас есть два разных файла для динамической компоновки, и 2) один из файлов имеет то же имя, что и статическая библиотека. –

Благодарим вас за ответ. Наверное, я не единственный, кто запутался в этой теме. Итак, как вы говорите, есть два типа .lib-файлов, которые создаются, когда необходима динамическая библиотека, а другая - статическая библиотека. Я не нашел другой файл Vendor.lib, поэтому, я думаю, я в первом случае ... Спасибо! – linello

Vendor.lib должен быть статически скомпилированной библиотекой. Если при связывании вам все равно нужен Vendor.dll, это похоже на то, что Vendor.lib - это скорее библиотека импорта, а не статическая библиотека.

Проверьте, не предоставил ли поставщик другой Vendor.lib (который должен быть немного больше вашего текущего .lib), который является статической библиотекой и пытается установить связь с этим. Если это так, вам не понадобится dll.

источник

2012-03-05 13:51:45 Fraser

К сожалению, у меня нет других .lib-файлов в этой библиотеке, поэтому я предполагаю, что я в динамической ссылке. Нет других способов включить DLL, а не копировать их в исполняемый каталог (или скопировать их в папку System32?) – linello

Если у вас есть доступ к источнику поставщика, вы можете скомпилировать vendor.lib самостоятельно как статическую библиотеку , В противном случае, если вам нужно использовать общую библиотеку lib, то ваш exe нуждается в доступе к ней во время выполнения, что означает добавление ее в папку с exe или помещение ее в папку, включенную в% PATH% (соглашение, являющееся System32). – Fraser

Динамическое и статическое связывание и развертывание в Visual Studio 2010

ответ

Смежные вопросы