Настройка линкера visual studio
Обновлено: 08.07.2024
Первое, что нам нужно сделать, прежде чем мы начнем программировать графику — это создать контекст OpenGL и окно приложения для рисования. Однако данные операции являются специфичными для каждой операционной системы, поэтому OpenGL целенаправленно пытается абстрагироваться от них. Это означает, что мы самостоятельно должны создать окно, определить контекст и обрабатывать пользовательский ввод.
К счастью, существует довольно много библиотек, которые обеспечивают необходимый нам функционал, при этом некоторые из них специально нацелены на работу с OpenGL. Эти библиотеки избавят нас от всей специфической работы, связанной с особенностями конкретной операционной системы. Наиболее популярными библиотеками являются: GLUT, SDL, SFML и GLFW. На этих уроках мы будем использовать библиотеку GLFW. Вы также можете использовать и любую другую библиотеку из предоставленного списка, т.к. установка и настройка для большинства из них аналогична установке и настройке GLFW.
Библиотека GLFW
Основное внимание на этом и следующем уроках уделяется изучению библиотеки GLFW, созданию корректного контекста OpenGL, а также простого окна, в котором мы и будем рисовать наши объекты. На этом уроке мы пошагово рассмотрим установку библиотеки GLFW, а также процесс сборки и компиляции программы в связке с GLFW.
Примечание: На момент написания данной статьи в качестве среды разработки мы будем использовать Microsoft Visual Studio 2019 (обратите внимание, что наши действия будут аналогичными и с более старыми версиями Visual Studio). Если же вы используете более старую версию Visual Studio (или вообще другую среду разработки), то можете быть спокойны, т.к. процесс установки и настройки GLFW аналогичен в большинстве IDE.
Сборка GLFW
Библиотеку GLFW можно скачать с официального сайта. Стоит отметить, что GLFW уже имеет предварительно скомпилированные бинарные и заголовочные файлы для Visual Studio 2010-2019, но для полноты картины их мы использовать не будем, а вместо этого вручную скомпилируем GLFW из исходного кода. Это делается для того, чтобы вы сами прочувствовали процесс компиляции библиотек с открытым исходным кодом, поскольку не каждая подобная библиотека будет предоставлять возможность скачать предварительно скомпилированные бинарные файлы. Итак, давайте загрузим пакет с исходным кодом.
Примечание: Мы будем собирать все библиотеки в формате 64-битных бинарных файлов, поэтому убедитесь, что скачиваете и используете именно 64-битные бинарные файлы.
После загрузки пакета с файлами исходного кода извлеките и откройте его содержимое. Нас интересуют следующие вещи:
библиотека, которая будет получена в результате компиляции;
Компиляция библиотек из исходного кода гарантирует, что полученная нами библиотека идеально подойдет для нашего процессора и операционной системы, в то время как предварительно скомпилированные бинарные файлы не всегда могут этим похвастаться (иногда они вообще недоступны для вашей системы). Однако проблема проектов, распространяющихся под эгидой открытого программного обеспечения, заключается в том, что не все используют одну и ту же IDE или систему сборки для разработки своего приложения, а это значит, что предоставленные файлы проекта/решения могут быть несовместимы с настройками IDE у других людей. Следовательно, каждый конечный пользователь должен настроить свой собственный проект/решение с учетом полученных *.с / *.cpp и *.h / *.hpp файлов, что почти всегда является довольно трудоемким и громоздким процессом. Но не спешите расстраиваться, для решения данной проблемы уже существует удобный инструмент сборки проектов под названием CMake.
CMake
CMake — это инструмент, который с использованием заранее определенных сценариев может из коллекции файлов исходного кода сгенерировать файлы проектов/решений под выбранную пользователем IDE (например, для Visual Studio, Code::Blocks или Eclipse). Он позволит нам из исходного пакета файлов GLFW создать файл проекта под среду разработки Visual Studio 2019, а затем данный файл мы сможем использовать для компиляции библиотеки. Но сначала нам нужно его скачать, а затем установить.
После установки CMake у вас будет 2 варианта:
запустить CMake из командной строки;
запустить CMake через графический интерфейс.
Поскольку мы не стремимся всё усложнять, то остановимся на варианте с использованием графического интерфейса. Для работы с CMake нам потребуется указать папку с файлами исходного кода проекта (в нашем случае glfw-3.3.2 ) и папку назначения для бинарных файлов. Для папки исходного кода мы собираемся выбрать корневую папку загруженного исходного пакета GLFW, а для папки сборки мы создадим новый каталог build :
После того, как мы прописали пути для исходной и целевой папок, нам нужно нажать кнопку Configure , чтобы CMake смог просмотреть исходные файлы GLFW и выбрать необходимые параметры для сборки.
В следующем окне необходимо задать используемую версию Visual Studio. Т.к. работать мы будем в Visual Studio 2019, то выбираем опцию "Visual Studio 16 2019" :
Далее CMake отобразит возможные варианты сборки библиотеки. Можно оставить значения по умолчанию и снова нажать кнопку Configure , чтобы сохранить настройки:
После установки параметров мы нажимаем кнопку "Generate" , в результате чего в папке build будут созданы необходимые файлы проекта.
Компиляция проекта
Теперь, зайдя в папку build , среди всего прочего можно увидеть файл с именем GLFW.sln , открываем его с помощью Visual Studio 2019:
Поскольку CMake сгенерировал файл проекта, который уже содержит соответствующие параметры конфигурации, нам остается лишь реализовать решение. При этом CMake должен был автоматически настроить вариант компилирования решения в виде 64-битной библиотеки. Благодаря этому мы получим скомпилированный файл библиотеки с именем glfw3.lib , который будет находиться в папке build/src/Debug .
После того, как мы создали библиотеку, нужно убедиться, что IDE знает, где найти данный файл, а также другие подключаемые файлы нашей программы OpenGL. Решить этот вопрос можно двумя способами:
Способ №1: Можно скопировать содержимое папки include проекта GLFW в соответствующую папку include вашей IDE или компилятора, а также скопировать полученный файл glfw3.lib в соответствующую папку /lib вашей IDE или компилятора. Данный способ вполне рабочий, но мы его не рекомендуем, так как новая установка IDE или компилятора приведет к тому, что вам заново придется подключать необходимые файлы.
Способ №2: Вы можете создать новую папку, которая будет содержать все заголовочные файлы и файлы из сторонних библиотек. На эту папку вы впоследствии сможете ссылаться из своей IDE или компилятора. Например, можно создать папку, в которой будут находиться папки Lib и Include . В них мы будем хранить все наши библиотечные и подключаемые файлы, которые собираемся использовать для наших OpenGL-проектов. Получается, что все сторонние библиотеки будут организованы в одном месте (и их можно будет совместно использовать на нескольких компьютерах). Однако, каждый раз при создании нового проекта, мы должны будем указывать IDE соответствующие пути к этим папкам.
Как только необходимые файлы будут сохранены в выбранном вами месте, мы сможем приступить к созданию нашего первого OpenGL-GLFW-проекта.
Наш первый проект
Для начала давайте откроем Visual Studio и создадим новый проект. Для этого нужно выбрать тип проекта "C++" , а далее — "Пустой проект" (не забудьте дать проекту подходящее имя):
Теперь у нас есть рабочее пространство для создания нашего самого первого OpenGL-приложения!
Линкинг проекта
Для того, чтобы наш проект мог использовать GLFW, нам нужно связать с ним полученную библиотеку. Это можно сделать, указав в настройках линкера, что мы хотим использовать библиотеку glfw3.lib , но проект пока не знает где её искать, т.к. все подобные файлы мы переместили в другую папку. Таким образом, сначала мы должны добавить эту папку в наш проект.
Для этого нажмите правой кнопкой мышки на имя проекта в "Обозреватель Решений" > "Свойства" . В появившемся окне выберите "Каталоги VC++" > "Каталоги библиотек" :
Здесь вы можете добавить свои собственные каталоги, чтобы проект знал, где искать необходимые файлы. Это можно сделать, вставив вручную путь до каталога или щелкнув по соответствующей строке и выбрав пункт <Изменить…> , в результате чего откроется следующее окно:
Здесь вы можете добавить столько дополнительных каталогов, сколько захотите, и с этого момента IDE при поиске файлов библиотек также будет просматривать и эти директории. Поэтому, как только вы подключите папку Lib из проекта GLFW, вы сможете использовать все файлы библиотек из этой папки. Аналогично обстоят дела и с добавлением папки Include для заголовочных файлов.
Поскольку для VS были указаны все необходимые файлы, то мы, наконец, можем связать GLFW с нашим проектом, перейдя в раздел "Компоновщик" > "Ввод" :
Чтобы связать библиотеку, нам нужно указать для компоновщика её имя. Так как библиотека называется glfw3.lib , то мы добавляем название этого файла в раздел "Дополнительные зависимости" (вручную или же через пункт <Изменить…> ), и с этого момента при запуске процесса компиляции GLFW будет связан с нашим проектом. В дополнение к GLFW мы также должны добавить ссылки на библиотеку OpenGL, но данные действия будут отличаться, в зависимости от (вашей) используемой операционной системы:
Библиотека OpenGL в Windows. Если вы используете операционную систему Windows, то необходимый нам файл библиотеки OpenGL32.Lib , входящий в пакет Microsoft SDK, уже есть в составе Visual Studio и не требует отдельной установки. Поскольку мы используем компилятор VS и работаем в операционной системе Windows, то всё, что вам нужно сделать — это добавить название файла OpenGL32.Lib к общему списку параметров компоновщика.
Больше того, если зайти в папку C:\Program Files (x86)\Windows Kits\10\Lib\[Номер_версии_SDK]\um\x86\, то и там можно встретить файл OpenGL32.Lib:
Библиотека OpenGL в Linux. Если вы работаете в операционной системе Linux, то вам нужно подключить библиотеку libGL.so с помощью ключей –lGL , добавляемых к параметрам вашего компоновщика. Если вы не можете найти данную библиотеку, то вам, вероятно, необходимо установить любой из пакетов: Mesa, NVidia или AMD dev.
Затем, после добавления библиотек GLFW и OpenGL в настройки компоновщика, вы сможете подключить заголовочные файлы GLFW следующей строкой кода:
Я пытаюсь переопределить мою точку входа в мое приложение, чтобы оно не использовало main (), потому что оно конфликтует с другим кодом, который я пытаюсь протестировать.
Я использую подсистему: CONSOLE, и выводит exe. Все работает, когда это определено как
Вещи компилируются нормально.
Затем я изменяю это на.
И в точке входа Visual Studio Linker я изменяю его с пустого значения на main_test. Я начинаю получать тонну (например, 3500+) ошибок связывания, связанных с libcpmtd.lib и других символов, которые отсутствуют в моих файлах obj, таких как __stdio_common_vsscanf, что, очевидно, встроенная функция, которую я нигде не вызываю.
Я получаю те же самые ошибки, если я оставляю свою функцию как main, показанную выше, и просто набираю main в качестве точки входа, так что это заставляет меня поверить, что что-то, что я делаю, неправильно. Любая помощь будет оценена, кажется, простая проблема, я не уверен, почему это так сложно.
Решение
Сначала вам нужно установить точка входа
Откройте диалоговое окно страниц свойств проекта. Для получения дополнительной информации см. Настройка
Свойства проекта Visual C ++.Нажмите на папку Linker.
Нажмите на страницу свойств Advanced.
Измените свойство точки входа.
и установить main_test
После я не до конца понимаю почему, но это нужно делать этот
Откройте диалоговое окно страниц свойств проекта. Для получения дополнительной информации см. Настройка
Свойства проекта Visual C ++.Нажмите на папку Linker.
Нажмите на страницу свойств ввода.
Измените свойство Force Symbol References.
и установить _mainCRTStartup для x86 или mainCRTStartup для х64.
Или сделайте это программно в вашем коде:
Обратите внимание, что main не по умолчанию точка входа. Точка входа для консольного приложения _mainCRTStartup какие звонки main , Поэтому, изменяя точку входа, вы теряете CRT, и вам приходится вручную реализовывать такие вещи, как получение аргументов командной строки. Для более детального просмотра Вот
UPD
Х отя общие принципы работы разделяемых библиотек в UNIX и Windows примерно одинаковые, есть ряд деталей, которые по невнимательности могут привести к проблемам.
Экспортирование символов
Самое главное отличие в том, что в Windows символы не экспортируются автоматически. В UNIX системах все символы по умолчанию видны пользователю разделяемой библиотеки, в то время как на windows программист должен явно указать, что экспортировать.
Есть три способа экспорта символов в DLL (и все три способа могут быть использованы вместе в одной библиотеке).
- В коде библиотеки, объявив __declspec(dllexport), например __declspec(dllexport) int my_exported_function(int x, double y);
- В вызове линкера, используя опцию /export:symbol_to_export программы link.exe LINK.EXE /dll /export:my_exported_function
- Передать линкеру файл объявления модулей (.def файл), используя опцию /DEF:def_file, и в этом файле добавить секцию EXPORT, которая включат символы для экспорта.
Если добавить сюда С++, первая опция самая простая, потом что занимается подгонкой имён функций за вас.
.LIB и другие связанные с библиотекой функции
Это подводи нас ко второму усложнению библиотек в Windows: информация об экспортированных символах, которые должен собрать компоновщик хранится не в самой DLL, а в соответствующей .LIB файле.
LIB файл, ассоциированный с DLL файлом, содержит информацию о представленных в DLL символах и их расположении. Программы, которые используют эту DLL, должны получать информацию из .LIB файла чтобы корректно разрешить все символы.
Для того чтобы всё стало ещё запутаннее - .LIB это ещё и расширение статических библиотек.
Существует большое количество файлов, связанный с Windows библиотеками
- library.DLL – непосредственно код библиотеки, который необходим программам для исполнения
- library.LIB – «импорт библиотеки», который описывает символы в разделяемой библиотеке. Этот файл генерируется только если DLL экспортирует какие-то символы; это файл необходим во время линков для всех, кто пользуется библиотекой
- library.EXP – «файл экспорта» для компонуемой библиотеки, необходимый для линковки бинарников с циклическими зависимостями
- library.ILK – генерируется если была использована опция /INCREMENTAL (енобходимая для инкрементальной линковки), и содержит информацию, необходимую для дальнейшей инкрементальной компоновки.
- library.PDB – генерируется, если была включена опция /DEBUG. Этот файл – база данных программы, которая содержит информацию для отладки библиотеки
- library.MAP – генерируется, если была использована опция /MAP. Содержит информацию о внутренней структуре библиотеки
Сравните с UNIX. Где информация из всех этих файлов обычно хранится непосредственно в файле библиотеки.
Импорт символов
Windows, кроме явного декларирования импортируемых символов, также позволяет сделать это непосредственно в коде, с помощью __declspec, что также несколько ускоряет работу.
Для Си нормальной практикой является объявление всех функций и глобальных переменных в заголовочном файле. Это приводит к парадоксальной ситуации, когда код внутри DLL, который определяет глобальные переменные и функции, вынужден экспортировать символ, а весь код вне DLL должен импортировать это символ.
Обычно из этой ситуации выходят посредством макроса в заголовочном файле
Если переменная препроцессора EXPORTING_XYZ_DLL_SYMS определена, то будет происходить экспорт, иначе импорт символа.
Циклические зависимости
Последняя сложность с DLL в том, что Windows требует, чтобы во время компоновки все символы бы разрешены. В UNIX можно присобачить библиотеку с неопределёнными символами, которые линкер никогда не видел, и в этой ситуации любая программа, которая извлекает эту библиотеку обязана его предоставить, или программа не сможет загрузиться. Windows таких слабостей не позволяет.
Для большинства систем это не проблема. Программы зависят от высокоуровневых библиотек, которые в свою очередь зависят от низкоуровневых библиотек, и всё компонуется в обратном порядке – сначала низкоуровневые библиотеки, потом высокоуровневые, потом программа.
Если же существуют циклически зависимости, то всё становится немного более трудоёмким. Если X.DLL нуждается в символе из Y.DLL, а Y.DLL в символе из X.DLL, то мы получаем проблему курицы и яйца; первая собираемая библиотека не сможет разрешить все свои символы.
Windows предоставляет выход из положения, который грубо можно описать так
- Сначала фальшивая сборка X. Выполняется LIB.EXE (не LINK.EXE) для генерации X.LIB файла, который будет таким же, как и сгенерированный LINK.EXE. X.DLL не генерируется, но создаётся X.EXP файл
- Нормально компонуется Y. Он используется X.LIB и возвращает Y.DLL и Y.LIB
- В конце, нормально собирается X, во время сборки которого добавляется X.EXP с первого шага. Будет использован Y.LIB файл и создан X.DLL. Компоновка пропустит шаг создания X.LIB (об этом укажет файл X.EXP)
Конечно, лучшим решением будет сделать так, чтобы циклических зависимостей не было.
Добавим С++
C++ добавляет кучу дополнительных возможностей в си, многие из которых взаимодействуют с линкером. Поначалу это не было проблемой, так как первые реализации си++ былы скорее фронтэндом к компилятору си, но дальнейшее совершенствование языка привело к тому, что линкер должен был улучшаться
Перегрузка функций и декорирование имён
Первое нововведение – это перегрузка функций, то есть существование нескольких функций с одним именем и разными типами аргументов (функции имеют разные сигнатуры).
Очевидно, это добавит проблем – если код обращается к функции max, то к какой именно?
Решение было названо декорированием имён, потому что информация о сигнатуре функции засовывается в переделанное имя функции. Функции с разными аргументами имеют разные имена.
Не буду углубляться в детали (разные реализации на разных платформах делают это по-разному), но вот как примерно выглядит объектный файл (напоминаю о nm – вашем верном друге)
Мы видим, что три функции max в объектном файле имеют три разных имени. Последние две буквы, по-видимому, кодируют типы данных аргументов, которые передаются в функцию: “I” для int, "f“ для float, “d” для double (всё намного усложняются, если вспомнить ещё и о класса, шаблонах, пространствах имён, перегруженных операторах и т.п.).
Стоит также отметить, что обычно есть способ конверсии пользовательских имён (недекорированных) и имён функций, видимых линкеру. Это делается с помощью либо отдельной утилиты (c++filt), либо с помощью опции в командной строке (--demangle для nm). В результате получи что-то вроде
Люди обычно запинаются на этой схеме декорирования, когда смешивают вместе код на си, и код на си++, потому что имена функций С++ модифицируются, а имена функций Си остаются как есть. Для решения проблемы в C++ можно обернуть объявление и определение сишных функций с помощью “extern C”, что говорит компилятору. По существу, директива говорит компилятору, что имена не надо декорировать, либо потому что это С++ функции, которые будут вызваны из Си кода, либо потому что это Си функции, которые будут вызваны из С++ кода.
Вот к примеру какая ошибка выпала бы, если бы мы вставили код из самого начала (см. первую часть) в С++ программу, забыв объявить её как extern c
Кстати, объявление кода extern c не работает для функций-членов класса (часть 7.5.4. стандарта С++).
Инициализация статических переменных
Следующая особенность С++, которая сильно влияет на работу линкера – это конструкторы. Конструктор – это часть кода, которая устанавливает содержимое объекта; концептуально, это похоже на инициализацию переменной начальным значением, но с ключевой особенностью – вовлечением в процесс произвольного участка кода.
Из предыдущих секций известно, что глобальная переменная может иметь начальное значение. В си конструирование инициализированной глобальной переменной делается просто: из data сегмента кода исполняемой программы копируется значение в нужную область оперативной памяти.
В C++ всё гораздо сложнее обычного копирования фиксированного значения, потому что весь код всех конструкторов в иерархии наследования класса должен запуститься, прежде чем основной код программы начнёт работать как надо.
Для преодоления этой трудности компилятор добавляет в объектный файл дополнительную информацию – список конструкторов, которые должны быть запущены для этого конкретного файла. Во время компоновки линкер собирается всю эту информацию в один большой список и добавляет код, который проходит по списку, вызывая эти глобальные конструкторы объектов.
Можно выследить эти списки, опять же, с помощью nm. Пусть есть такой код на С++
Для этого кода nm выдаст (без декорирования)
Или так, с декорированием
Здесь много всего интересного, но нас волнуют только два вхождения символов с классом W (что значит weak), а также с секциями с именами вроде .gnu.linkonce.t.stuff. Это маркеры глобальных конструкторов объектов. Соответствующие им имена – одино для каждого из конструкторов.
Шаблоны
В предыдущих разделах мы привели пример функции с одним именем max и тремя наборами аргументов. Тем не менее, код всех трёх функций идентичен, а копирование и вставка одного и того же кода вызывает досаду.
С++ представил шаблоны, которые позволяют для таких случаев писать код единожды и навсегда. Создадим заголовочный файл max_template.h с единственным кодом для max
Для использования шаблонной функции подключим его
Этот С++ файл использует как max<int>(int ,int). Так и max<double>(double, double), но разные файлы С++ могут использовать и другие реализации, например max<float>(float,float), или даже max<MyFloatingPointClass>(MyFloatingPointClass,MyFloatingPointClass).
Каждая их этих разных реализаций включает разный машинный код. Во время компиляции линкер должен убедиться в том, что код всех реализаций добавлен, а также что нет ненужных реализаций, которые будут раздувать код.
Как это делается? Обычно используют два способа – удалением дублированных реализаций, и откладыванием инстанциирования до этапа компоновки.
В первом случае, каждый объектный файл включает все свои реализации шаблонной функции.
Видно, что представлены как max<int>(int, int), так и max<double>(double, double).
Эти определения обозначены как weak-символы, что значит, что в конечной исполняемой программе линкер может исключить все эти символы (оставив как минимум один). Самый большой недостаток такого подхода в том, что на жёстком диске объектные файлы будут занимать больше места.
Второй подход (который используется компилятором Solaris C++) вообще не включать код этих функций в объектный файл. Оставляя символы неопределёнными. Во время компоновки линкер может собрать все эти неопределённые символы и тогда уже сгенерировать для них код и включить в программу.
Такой подход уменьшает размер объектных файлов, однако требует от компилятора знать, в каких заголовочных файлах какие шаблоны объявлены и уметь вызывать компилятор для генерации кода. Всё это замедляет линковку.
Динамически подгружаемые библиотеки
Последняя особенность, которую мы обсудим, это динамическое подключение разделяемых библиотек. В предыдущем разделе рассказано о том, что финальная компоновка откладывается до момента работы программы. На современных системах она может быть отложена ещё дальше.
Это делается с помощью двух системных вызовов dlopen и dlsym (грубые аналоги на Windows это LoadLibrary и GetProcaddress).Првый вызов по имени библиотеки подгружает её в адресное пространство исполняемого процесса. Конечно, эта библиотека сама может содержать неопределённые символы и её подгрузка приведёт к вызову dlopen.
Также можно указать dlopen что в этом случае делать. Флаг RTLD_NOW приведёт к подгрузке всех необходимых библиотек, а RTLD_LAZY будет подключать библиотеки по одной, по мере необхомости. Первый подход гораздо медленнее, но во во втором случае возможна ситуация, когда дополнительная библиотек не найдена, что приведёт к завершению работы программы.
У символа из динамически подгружаемой библиотеки нет имени. Тем не менее, как обычно в программировании, это решается ещё одним уровнем косвенной адресации. В этом случае, используя указатель на символ, а не обращаясь к нему по имени. Системный вызов dlsym принимает строковый параметр – имя символа – и возвращает указатель на него (или NULL, если найти не удалось).
Взаимодействие с возможностями С++
Каким же образом вышеприведённая динамическая загрузка вязана с возможностями С++, которые влияют на поведение линкера?
Первое наблюдение – декорирование имён достаточно каверзное. Вызов dlsym ищет символ по имени, это имя должно быть видимым компоновщику; поэтому именно декорированное имя должно быть в качестве аргумента. Из-за того, что способ модификации имён не стандартизирован и отличается от платформы к платформе, почти невозможно кроссплатформенно найти адрес символа динамически. Если вам и посчастливилось работать только с одним компилятором и покопаться в его внутренностях, есть ещё проблемы – кроме чистых С-подобных функций вам придётся тащить разные виртуальные таблицы методов и пр.
Обычно проще всего придерждиваться одного компилятора, оборачивать точку входа в extern c, которую легко получить с помощью dlsym. Эта точка входа может быть фабричным методом, возвращающим указатели на полные экземпляры С++ классов.
Компилятор может ещё достать конструкторы для глобальных объектов, открыв библиотеку с помощью dlopen, так как существует набор спецсимволов, которые будут вызваны при загрузке или выгрузке библиотеки. В UNIX системах это _init и _fini, в GNU __attribute__((constructor)) или . __attribute__((destructor)). В Windows DllMain с параметрами или DLL_PROCESS_ATTACH и DLL_PROCESS_DETACH.
установлено, визуальная студия сборка будет автоматически ссылку в `.файлы lib для всех проектов (библиотек DLL, библиотеки), что этот проект зависит от будет "в статике" и связаны.
*Сторона* примечание: по неизвестным причинам Microsoft изменил, как зависимостей, работал в VS2010** и вы теперь должны добавить зависимость непосредственно к проекту
и особенно увидеть здесь (acutal вопрос следует)
Может кто объяснит, что это значит, или: что-то "Библиотека зависимость" и параметр компоновщика на самом деле делать в Visual Studio 2010 с?
Вы должны дать установку на нужное значение, чтобы внести ясность:
2017 Перезаезд. Ура.
МНОГАБУКАФ.
Этот вариант устанавливает значение по умолчанию<суп>(а) в</SUP-серфинг> за фактическое библиотеки ссылка зависимостей на каждый проект ссылка. Если каждая ссылка на проект LinkLibraryDependecies`, то это по сути бессмысленно.
(а): это действительно должны быть одинаковыми для всех конфигурации (debug/release) и платформы (Win32/x64) или что-то получить очень сложно.
Подробности
Суть в том, как этот параметр вставлен в файл vcxprj и как по умолчанию работы в
` параметр в файла MSBuild.
Настройки в диалоговом окне компоновщика, как показано выше, вставляется как:
Что это действительно в файл заданного расширением vcxproj (или при выходе из .реквизит выйти), является **установить значение по умолчанию значение зависимостей библиотеки Ссылка`** для каждого зависимость проекта от рамок и ссылок в диалоге настроек VS2010 ВК --
И это важно, поскольку, когда вы добавляете новый проект, по умолчанию запись в файл vcxproj будет выглядеть так:
Читайте также: