Как узнать разрядность компилятора visual studio
Если вы используете компилятор командной строки (csc.exe), вы можете проверить справку для просмотра версии (также вам нужно знать версию Framework в любом случае:
Вот короткая версия его ответа.
В то время как это не отвечает на ваш вопрос напрямую, я помещаю это здесь, поскольку Google привнес эту страницу в первую очередь в мои поиски, когда я искал эту информацию.
Через dll
Вы также можете изменить версию, пожалуйста, выполните следующие шаги.
Откройте окно свойств проекта:
Откройте командную строку Visual Studio и просто введите csc и нажмите Enter.
Вы увидите следующее:
Для Windows вы запускаете dev в строке программы/поиска и выбираете команду командной строки разработчика для VS. Тогда вы собираетесь просто запустить
Теперь вы получаете информацию, аналогичную
Для Windows и если вы начинаете с CMD-терминала
Из командной строки разработчика введите
Если вы используете VS2015, выполните следующие действия, чтобы узнать то же самое:
- Щелкните правой кнопкой мыши на проекте.
- Нажмите на вкладку Свойства.
- В окне свойств выберите опцию Build.
- В этом нажмите на кнопку Advance.
- Там вы узнаете языковую версию.
Ниже изображения показывают шаги для того же:
Благодаря @fortesl и этому ответу
Узнать версию компилятора по итоговой программе
У меня есть исполняемый файл. Достоверно известно, что он скомпилирован в чём-то из пакета Visual Studio. Можно ли узнать версию компилятора и студии, с помощью которых этот файл был создан?
В общем случае это сделать крайне сложно. Но обычно это достаточно легко. Для этого понадобится программа Dependency Walker — раньше она шла с студией, а сейчас можно просто поискать в интернете (или любая другая, которая показывает, какие dll требуются программе). В списке dll ищем что то похожее на VC*XXX.DLL , где * — какие то символы, ХХХ — цифры. По цифрам легко угадать, к примеру VCRUNTIME140.DLL — это компилятор от 2015 студии (версия компилятора 14.0). Другие соостветствия можно посмотреть хоть в wikipedia.
2017 студия умеет использовать компилятор от 2015 студии. Поэтому, если версию компилятора легко угадать, то версию студии часто просто не возможно (никто не мешает писать код в блокноте или visual studio code).
Также существуют разные программы, которые ищут "отпечатки компилятора" (fingerprint). Например, PEiD. Но большинство таких программ обычно являются "инструментами взломщика".
Есть ли способ определить, какая версия Visual Studio использовалась для компиляции статической библиотеки?
У меня есть коллекция статических библиотек (.lib) файлы, один из которых может быть построен с другой версией Visual Studio. Это приводит к сбою генерации кода проекта, который связывается со всеми из них. Есть ли способ определить, какая версия Visual Studio использовалась для компиляции статической библиотеки?
для библиотек выпуска маловероятно, что вы сможете определить версию.
для библиотек отладки можно использовать команду dumpbin:
манифест сборки должен находиться в начале дампа и содержать версию CRT, требуемую библиотекой, а также полный путь к компилятору, используемому для построения библиотеки.
для исполняемых файлов и DLL вы можете получить версию компоновщика с помощью dumpbin; он находится под " необязательным заголовком Значения"
возможно, кто-то еще знает способ получить версию для библиотек выпуска; мне, конечно, тоже интересно, если они есть.
Я всегда использовал что-то вроде (в окне cygwin):
компилятор вставляет путь компилятора в библиотеку при построениях отладки, а расположение компилятора Visual Studio по умолчанию находится под путем, который включает текст "Visual Studio".
Я нашел этот метод много лет назад через немного провидчества, и он еще не потерпел неудачу.
Это имеет то преимущество, что его легко запомнить, если вы знакомы с инструментами командной строки Unix.
Если у вас есть соответствующий .PDB файлы, то вы можете увидеть версию компилятора оттуда с помощью инструмента, как Pdb Инспектор.
или откройте PDB в шестнадцатеричном средстве просмотра и найдите строку "Microsoft (R) Optimizing Compiler". Версия будет иметь четыре 2-байтовых шестнадцатеричных значения непосредственно перед этой строкой, как в этом примере:
версия, таким образом, HEX 13 00, 00 00, 6E 5D, 00 00 или 19.0.23918.0.
Если статическая библиотека была написана на C++ и была построена с MSVC 2010 или более новой версией, директива FAILIFMISMATCH могла быть помещена компилятором в объектные файлы.
Я не могу найти официальный документ от Microsoft о директиве FAILIFMISMATCH, но, похоже, он используется компоновщиком для обнаружения несовместимости между версиями стандартной библиотеки C++.
вы можете использовать следующую команду для распечатки этих директив из статического библиотека:
(или используйте способ, который mheyman упомянул, если вы предпочитаете cygwin или msys)
результат может быть похож на этот:
обратите внимание на первую директиву: "_MSC_VER=NNNN". По моему наблюдению, NNNN всегда соответствует версии компилятора, используемой для создания объектного файла. В моем случае, xyz.lib был создан с обновлением MSVC 2015 3, его версия компилятора C++ — 19.00.24215, поэтому он поместил /FAILIFMISMATCH: "_MSC_VER=1900" в объект файл.
можно найти подробное сопоставление между версией Visual Studio и версией компилятора Microsoft C/C++здесь.
был бы эквивалент в управляемом C++ / CLI
Visual Studio включает в себя компиляторы, компоновщики и другие инструменты C++, подходящие для создания версий приложений в зависимости от платформы приложений, которые могут выполняться в 32-разрядной, 64-разрядной или основанной на ARM версии операционной системы Windows. Другие дополнительные рабочие нагрузки Visual Studio позволяют использовать инструменты C++ для других платформ, таких как iOS, Android и Linux. Архитектура сборки по умолчанию использует 32-разрядные инструменты x86 для сборки 32-разрядного машинного кода x86 Windows. Но, скорее всего, у вас 64-разрядный компьютер. При установке Visual Studio в 64-разрядной операционной системе Windows для 64-разрядных собственных компиляторов и кросс-компиляторов x64 доступны дополнительные ярлыки командной строки разработчика. Вы можете воспользоваться преимуществами процессора и памяти, доступной для 64-разрядного кода, с помощью 64-разрядного набора инструментов x64 при сборке кода для процессоров x86, x64 или ARM.
Использование ярлыка 64-разрядной командной строки разработчика
Чтобы открыть эти командные строки в Windows, в меню Пуск откройте папку для вашей версии Visual Studio и выберите одну из командных строк разработчика x64 с собственными инструментами или инструментами кросс-компиляции.
Для вызова этих командных строк в Windows 8.1 на экране Пуск откройте плитку Все приложения. Под заголовком для установленной версии Visual Studio откройте папку Visual Studio (в более ранних версиях Visual Studio она может называться Инструменты Visual Studio). В более ранних версиях Windows выберите Пуск, разверните узел Все программы и откройте папку для вашей версии Visual Studio (и более ранних версий Visual Studio — Инструменты Visual Studio). Дополнительные сведения см. в разделе Ярлыки командной строки разработчика.
Использование файла Vcvarsall.bat для настройки 64-разрядной архитектуры сборки
Конфигурации собственных инструментов сборки или кросс-компилятора можно использовать в командной строке с помощью командного файла vcvarsall.bat. Этот командный файл настраивает путь и переменные среды, которые включают конкретную архитектуру сборки в существующем окне командной строки. Дополнительные инструкции см. в разделе Расположения командных файлов разработчиков.
Примечания
Сведения о различных инструментах, входящих в состав каждого выпуска Visual Studio, см. в разделе Инструменты и функции Visual C++ в выпусках Visual Studio.
При установке рабочей нагрузки C++ в Visual Studio Installer всегда устанавливается 32-разрядная версия собственных инструментов и инструментов кросс-компиляции x86 для сборки кода x86 и x64. Если вы включаете рабочую нагрузку универсальной платформы Windows, также устанавливаются инструменты кросс-компиляции x86 для сборки кода ARM. Если вы установите эти рабочие нагрузки в 64-разрядной версии процессора x64, вы также получаете 64-разрядные собственные инструменты и инструменты кросс-компиляции для сборки кода x86, x64 и ARM. 32-разрядные и 64-разрядные инструменты создают идентичный код, однако 64-разрядные инструменты поддерживают больше памяти для предкомпилированных символов заголовков и оптимизации всей программы (параметры /GL и /LTCG). В случае превышения ограничений памяти при использовании 32-разрядных инструментов попробуйте 64-разрядные инструменты.
В интегрированной среде разработки все сведения, необходимые для построения проекта, предоставляются в виде свойств. Эти сведения включают в себя имя приложения, расширение (например, DLL, EXE, LIB), параметры компилятора, параметры компоновщика, параметры отладчика, настраиваемые этапы сборки и многие другие компоненты. Как правило, для просмотра и изменения этих свойств используются страницы свойств. для доступа к страницам свойств выберите Project свойствапроекта в главном меню или щелкните правой кнопкой мыши узел проекта в обозреватель решений и выберите пункт свойства.
Свойства по умолчанию
При создании проекта система задает значения для различных свойств. Значения по умолчанию варьируются в зависимости от типа проекта и параметров, выбранных в мастере приложений. Например, проект ATL имеет свойства, связанные с MIDL-файлами, но эти свойства отсутствуют в базовом консольном приложении. В области "Общие" на страницах свойств отображаются свойства по умолчанию:
Применение свойств к конфигурациям сборок и целевым платформам
Некоторые свойства, такие как имя приложения, применяются ко всем вариантам сборки и целевым платформам, будь это сборка отладки или выпуска. Однако большинство свойств зависит от конфигурации. Чтобы создать правильный код, компилятор должен иметь как конкретную платформу, в которой будет выполняться программа, так и конкретные параметры компилятора. Поэтому при задании свойства важно обратить внимание на ту конфигурацию и платформу, к которым должно применяться новое значение. Должен ли он применяться только для отладки сборок Win32 или должен также применяться к отладке ARM64 и отладке x64? Например, для свойства оптимизации по умолчанию задано значение максимизировать скорость (/O2) в конфигурации выпуска, но оно отключено в конфигурации отладки.
Вы всегда можете видеть и изменять конфигурацию и платформу, к которым должно применяться значение свойства. На следующем рисунке показаны страницы свойств с элементами управления конфигурацией и сведениями о платформе в верхней части. Если свойство оптимизации задано здесь, оно будет применяться только для отладки сборок Win32, текущей активной конфигурации, как показано красными стрелками.
На следующем рисунке показана та же страница свойств проекта, но конфигурация изменена на выпуск. Обратите внимание на другое значение для свойства "Оптимизация". Кроме того, обратите внимание, что активной конфигурацией по-прежнему является отладка. Здесь вы можете задать свойства для любой конфигурации, а не только активной.
Целевые платформы
Целевая платформа относится к типу устройства и операционной системы, на которых будет выполняться исполняемый файл. Вы можете создать проект для нескольких платформ. Доступные целевые платформы для проектов C++ зависят от типа проекта. В их число входят только Win32, x64, ARM, ARM64, Android и iOS. Целевая платформа X86, которую вы могли заметить в Configuration Manager, идентична Win32 в собственных проектах C++. Win32 означает 32-разрядную версию Windows, а x64 — 64-разрядную. Дополнительные сведения об этих двух платформах см. в разделе Запуск 32-разрядных приложений.
Дополнительные сведения настройке свойств отладочной сборки см. в следующих разделах:
Параметры компилятора и компоновщика C++
Параметры компилятора и компоновщика C++ находятся в узлах C/C++ и Компоновщик на панели слева в разделе Свойства конфигурации. Эти параметры непосредственно преобразуются в параметры командной строки, которые будут переданы компилятору. Чтобы ознакомиться с документацией по конкретному параметру, выберите параметр в центральной области и нажмите клавишу F1. также можно просмотреть документацию по всем параметрам в MSVC параметры компилятора и параметры компоновщика MSVC.
Значения каталога и пути
MSBuild поддерживает использование констант времени компиляции для определенных строковых значений, таких как включаемые каталоги и пути, называемые макросами. макрос может ссылаться на значение, определенное Visual Studio или системой MSBuild, или на значение, определенное пользователем. Макросы выглядят как $(macro-name) или %(item-macro-name) . Они представлены на страницах свойств, на которых можно ссылаться и изменять их с помощью редактора свойств. Вместо жестко запрограммированных значений, таких как пути к каталогам, используйте макросы. Макросы упрощают совместное использование параметров свойств между компьютерами и версиями Visual Studio. Кроме того, можно обеспечить правильное участие в параметрах проекта в наследовании свойств.
На следующем рисунке показаны страницы свойств для проекта Visual Studio C++. в левой области выбрано правило VC++ каталоги , а на правой панели перечислены свойства, связанные с этим правилом. Значения свойств часто являются макросами, например $(VC_SourcePath) :
Для просмотра значений всех доступных макросов можно использовать Редактор свойств .
Предустановленные макросы
Глобальные макросы:
Глобальные макросы применяются ко всем элементам в конфигурации проекта. Глобальный макрос имеет синтаксис $(name) . Пример глобального макроса — свойство $(VCInstallDir) , которое сохраняет корневой каталог установки Visual Studio. Глобальный макрос соответствует элементу PropertyGroup в MSBuild.
Макросы элементов
Макросы элементов имеют синтаксис %(name) . Для файла макрос элемента применяется только к этому файлу, — например, можно использовать, %(AdditionalIncludeDirectories) чтобы указать каталоги включаемых файлов, которые применяются только к конкретному файлу. Этот тип макроса элемента соответствует метаданным ItemGroup в MSBuild. При использовании в контексте конфигурации проекта макрос элемента применяется ко всем файлам определенного типа. Например, свойство конфигурации определений препроцессора C/C++ может принимать макрос элемента, который применяется ко всем cpp-файлам в проекте. Этот тип макроса элемента соответствует метаданным ItemDefinitionGroup в MSBuild. Дополнительные сведения см. в разделе Определения элементов.
Пользовательские макросы
Вы можете создавать пользовательские макросы для использования в качестве переменных в сборках проекта. Например, можно создать пользовательский макрос, предоставляющий значение пользовательскому шагу сборки или пользовательскому средству сборки. Пользовательский макрос — это пара "имя-значение". Для доступа к этому значению в файле проекта используется нотация $(name) .
Пользовательский макрос хранится на странице свойств. если проект еще не содержит страницу свойств, его можно создать, выполнив действия, описанные в разделе общий доступ или повторное использование Visual Studio параметры проекта.
Создание пользовательского макроса
В левой области диалогового окна выберите Пользовательские макросы. В правой области нажмите кнопку Добавить макрос, чтобы открыть диалоговое окно Добавление пользовательского макроса.
В диалоговом окне задайте имя и значение для макроса. Кроме того, можно установить флажок Задание данного макроса в качестве переменной среды в среде сборки.
Редактор свойств
Редактор свойств можно использовать для изменения некоторых строковых свойств и выбора макросов в качестве значений. Чтобы открыть редактор свойств, выберите свойство на странице свойств, а затем нажмите кнопку со стрелкой вниз справа. Если раскрывающийся список содержит Правка >, можно выбрать его, чтобы отобразить редактор свойств для этого свойства.
В редакторе свойств можно нажать кнопку Макросы, чтобы просмотреть доступные макросы и их текущие значения. На следующем рисунке показан редактор свойств для свойства Дополнительные каталоги включаемых файлов после нажатия кнопки Макросы. Если установлен флажок наследовать от родительского объекта или проекта по умолчанию и добавить новое значение, то оно добавляется к любому значению, наследуемому в данный момент. Если снять флажок, новое значение заменяет наследуемые значения. В большинстве случаев следует не снимать этот флажок.
Добавление каталога включения к набору каталогов по умолчанию
При добавлении каталога включения в проект важно не переопределять все каталоги по умолчанию. Правильный способ добавления каталога — добавить новый путь, например " C:\MyNewIncludeDir\ ", а затем добавить $(IncludePath) макрос к значению свойства.
Быстрый просмотр и поиск всех свойств
Без префикса:
поиск только в именах свойств (подстрока без учета регистра).
" / " или " - ":
поиск только в параметрах компилятора (префикс без учета регистра)
v :
поиск только в значениях (подстрока без учета регистра).
Задание переменных среды для сборки
компилятор MSVC (cl.exe) распознает определенные переменные среды, в частности LIB ,, LIBPATH PATH и INCLUDE . при построении с помощью интегрированной среды разработки свойства, заданные на странице свойств каталоги VC++ , используются для задания этих переменных среды. если LIB LIBPATH значения, и INCLUDE уже заданы, например Командная строка разработчика, они заменяются значениями соответствующих свойств MSBuild. затем сборка добавляет значение свойства VC++ каталоги исполняемых каталогов в PATH . Для задания пользовательской переменной среды можно создать пользовательский макрос и затем установить флажок Задание данного макроса в качестве переменной среды в среде сборки.
Задание переменных среды для сеанса отладки
В правой области измените параметры проекта Среда или Объединение среды, а затем нажмите кнопку ОК.
Содержание раздела
Совместное или повторное использование параметров проекта Visual Studio
Создание .props файла с настраиваемыми параметрами сборки, которые можно использовать совместно или повторно.
Наследование свойств проекта
Описывает порядок вычисления для .props .targets .vcxproj переменных среды,, файлов и в процессе сборки.
Изменение свойств и целевых объектов без изменения файла проекта
Создание временных параметров сборки без изменения файла проекта.
Вопрос в следующем. Существует ли какой-нибудь кроссплатформенный метод определения разрядности платформы на этапе препроцессинга?
Гоголь показывает только:
и какое-то дикое обсуждение:
Но нам нужно другое - способ, работающий и в GCC Linux, и в винде, и с разными компиляторами.
У кого-нибудь готовое условие не завалялось?
где-то так наверное
Вот потому что ищещь по виндовым терминам, потому и находишь только win64. Эти архитектуры называются x86, amd64/x86-64.
Так наверно или точно?
> Так наверно или точно?
первое для gcc, второе для msvc, надо что-то еще - ищи сам
неужели так сложно (U)LONG_MIN/MAX проверить?
а где вы псдений раз видели 32-хбитную платформу?
толсто, у меня все домашние системы 32-битные.
Просто в другом месте нахожу:
верить не надо, есть документация, для gcc:
там множество решений
Спасибо, на этом и остановлюсь.
я имею в виду 32-хбитный процессор. Все процессоры, выпущенные за последние года 3 имеют 64-битную архитектуру. Давайте все таки не считать пользователей за дуарков, которые будут ставить 32-хбитную ОС на 64-хбитный процессор.
А корректно ли определять через размер size_t?
> А корректно ли определять через размер size_t?
технически - да, но в стандарте, насколько я знаю, размер size_t не указан, т.е. может зависеть от реализации
> Давайте все таки не считать пользователей за дуарков, которые будут ставить 32-хбитную ОС на 64-хбитный процессор.
Но такие есть, и им пофигу на разрядность.
да? Жаль. Я всех своих знакомых на работе пересадил на x86_64 OS (Ubuntu в данном случае)
Пересади меня! А то мне с моим старым ноутом у которого всего 1гб памяти и процом core duo который не держит 64бита как-то ссыкотно переходить.
Вот лол так лол.
> Я всех своих знакомых на работе пересадил на x86_64 OS (Ubuntu в данном случае)
мой п4, которому лет 6 - написано, что умеет amd64 - на деле - нет(
>верить не надо, есть документация
Everybody lies. Это только на IA-64 определено (Itanium).
ясно, да - по названию можно было догадаться, поверил описанию
Но зачем? Если памяти меньше 4G, Вы ничего не выиграете, а наоборот, т.к. 64х-битные приложения требуют больше памяти.
Это действительно нужно? Обычно лучше использовать типы известного размера, например int64_t, u_int32_t и т.п. (см. /usr/include/sys/types.h).
> например int64_t
ISO/IEC 9899:1999 → 7.18.1.1 → 3) These types are optional.
Хуже того: их нет даже в MSVC, поэтому там придётся использовать __int64. Он был приведён для примера.
> Хуже того: их нет даже в MSVC
> их нет даже в MSVC
> даже в MSVC
/me подавился пивом…
на винде оно sizeof(long) не зависит от архитектуры x86/x86-64
Я бы распарсил в cmake uname. Или из /proc можно попытаться информацию извлечь. А вот как это сделать в мастдае - понятия не имею.
Где? В своей коробочной русской MS Visual Studio 2008 Professional не нашёл.
Осторожнее надо. IMO сей компилятор - второй по распространённости, если не первый.
Про кроccкомпиляцию мусье не слышал?
Зато для линукса это самое простое решение. А как там в мастдае - понятия не имею. Но для cmake можно сделать проверку на ОС и, в зависимости от нее, вызывать тот или иной велосипед.
кроccкомпиляция подразумевает сборку и под линукс, но другой архитектуры, как самый простой вариант - 32 бита из под 64-битной системы
У ТСа такой задачи не было. Так что не запутывайте.
И, кстати, ЕМНИП, без ВМ не получится (я уже как-то пытался себе дженту 64-битную закомпилять, не пользуясь ВМ - ничего не вышло).
> И, кстати, ЕМНИП, без ВМ не получится
В мане написано, что это для сборки вроде 32бита из-под 64-х. Но что-то у меня, несмотря на всякие ключики в make, 64-битное ядро компилироваться 32-битным gcc не стало.
> Но что-то у меня, несмотря на всякие ключики в make, 64-битное ядро компилироваться 32-битным gcc не стало.
КО говорит, что ты просто не умеешь
Зато для линукса это самое простое решение.
Заканчивай уже пить пиво, оно у вас там с веществами, однозначно.
Молодцы, оперативно работают. Но закладываться на последнюю версию компилятора неправильно IMO.
Сделать проверку компилятора проще на порядки. И безо всяких cmake, а прямо в коде. Для Windows есть набор define'ов, которые устанавливают все компиляторы, а в Linux с вероятностью 99% используется GCC. Способа, который работал бы везде и всегда, AFAIK нет. Даже если бы он был в стандартах, всегда найдётся кто-нибудь, кто им соответствует не полностью.
> Молодцы, оперативно работают.
>Существует ли какой-нибудь кроссплатформенный метод определения разрядности платформы на этапе препроцессинга?
Для начала надо определить понятие разрядности платформы. И преследуемые цели. Правильная постановка вопроса - это половина ответа. Иначе будет «что 100? а что приборы?». Реализация С на 64-битовой платформе теоретически может быть полностью 32-битовой (без 64-битовых целых типов и указателей). Как и наоборот.
Нужно написать программу, использующую существующие библиотеки. Есть файлы *.dll, *.lib и *.h соответственно. В документации к библиотеке написано, она была создана с помощью компилятора Visual C++ 2008. Не знаю, имеет ли значение, вроде как библиотека используют в т.ч. MFC.
- Что бы эти библиотеки можно было использовать, на компьютере должен быть установлен Redistributable Package Visual C++ 2008? Или можно более новую версию, без старой?
- Правильно ли я полагаю, что библиотеки были созданы в visual studio 2008, т.к. в документации указан компилятор Visual C++ 2008?
- Для написания программы, использующей данные библиотеки, обязательно ли нужно тогда использовать, соответственно, vs2008? Или можно, скажем студию 2010 или 2017? Нужны ли тогда дополнительные "телодвижения"? Если "инструкция" большая, где об этом почитать?
- Как узнать версию компилятора, в которой была создана библиотека, например, не имея документации к ней?
3 ответа 3
Все зависит от того, как библиотека была построена. Если .dll была собрана со статической линковкой и экспортирует функции как extern "C" , то Redistributable Package для нее не требуется, и скорее всего (не проверял, так что неточно) ее можно будет использовать с более новыми версиями студии.
Если библиотека была собрана с динамической линковкой, то использовать ее получится только в VS 2008, и для работы ее потребуется либо установленная VS 2008, либо Redistributable Package, причем именно 2008.
Компиляторы разных студий по объектному формату несовместимы, причем несовместимым может быть даже тот же самый компилятор после апдейта. Сам влетел в такую ситуацию пару месяцев назад после обновления VS 2017. Пришлось перекомпилировать много чего, включая чужие библиотеки, это было непросто. Теперь от апдейтов как от чумы, хотя VS 2017 кривой до изумления.
Правильно ли я полагаю, что библиотеки были созданы в visual studio 2008, т.к. в документации указан компилятор Visual C++ 2008?
Необязательно в студии, компилятор и прочее можно пускать и из командной строки. Но в целом да, так и есть.
Как узнать версию компилятора, в которой была создана библиотека, например, не имея документации к ней?
Как-то так. Точно вам разве что в саппорте MS скажут. В целом быстрее будет разобраться экспериментируя.
1) Это зависит от того, имеются ли в библиотеке специфические вызовы и ресурсы. Сказать однозначно, нужен пакет или нет, невозможно. Нужно запустить и посмотреть.
2) Теоретически, библиотеки могут быть собраны в любом окружении, даже на другой операционной системе. Но обычно, если говорят, что проект/библиотека собираются в VS C++ 2008 , то так оно и есть.
3) Степень телодвижений для использования библиотеки зависит от того, как именно эта библиотека реализована. Тут нет общего правила. Хорошим тоном считается сокрытие всей библиотечной магии под сишными интерфейсом. Такой подход позволяет выставить наружу простой интерфейс, который может быть использован различными компиляторами и даже другим языковым окружением. Обычно, при использовании сишного интерфейса значение имеет только разрядность используемого вами компилятора - она должна совпадать с разрядностью компилятора, которым библиотека была собрана.
Однако, в мире C++ очень часто бывает так, что в интерфейс библиотеки просачиваются тонкости реализации используемого компилятора. В этом случае библиотеку очень тяжело заставить работать, потому что исключения, шаблоны, искажения имен и вот это все - определяется реализацией и может меняться даже при смене настроек компиляции в одном и том же компиляторе.
4) Версия используемого компилятора вам мало чем поможет.
Стандарт C++17 занимает 1700 страниц. Больше половины этого - поведение, определяемое реализацией, то есть - разработчиками компиляторов.
Поэтому, если библиотеку не удается подключить к вашему компилятору, при условии, что компилятор имеет подходящую разрядность, то лучше найти другую библиотеку, которая предоставит классический C -интерфейс.
Читайте также: