Ошибка LNK2005 уже определена при обновлении решения C ++ / Fortran до VS 2013

Трудно быть полезным с таким небольшим количеством деталей, но вот некоторые вещи, о которых нужно подумать.

Зависимый от платформы код

Не исключено, что ваш код виноват — например, вы могли бы иметь #ifdef код, который зависит от создаваемой платформы. Это может означать, что ваши сборки Win32 и Win64 компилируют разный код. Но тот факт, что ваш код успешно собирается в Visual Studio 2010, говорит о том, что это маловероятно.

Разновидностью этого может быть стандартный заголовок, который изменился между Visual Studio 2010 и Visual Studio 2013 в зависимости от платформы. Но опять же это маловероятно — вещи не должны ломаться только потому, что вы включаете заголовок.

Зависимые от платформы свойства

Распространенным источником ошибок сборки в мультиплатформенных решениях является разница в настройках проекта для двух платформ. Конечно, некоторые свойства предполагаемый отличаться между Win32 и Win64, но другие должны быть идентичными или должны быть «одинаковыми» в том смысле, что они используют 32- и 64-разрядные версии одного и того же параметра.

Стоит просмотреть все настройки вашего проекта на предмет непреднамеренных различий между двумя платформами. Так как вы получаете ошибку компоновщика, может быть особенно целесообразно проверить настройки компоновщика «Дополнительные каталоги библиотеки» и «Дополнительные зависимости». Помните, что код x64 должен ссылаться на версии файлов x64 — либо с использованием другого имени файла, либо путем ссылки на файл в каталоге, специфичном для x64.

Один из способов поиска вариантов свойств — открыть Свойства проекта и установить для «Платформы» значение «Все платформы». Затем найдите отдельные свойства со значением «<разные варианты>». Я думаю это работает в Visual Studio 2013, конечно же, работает в Visual Studio 2015 (извините, VS 2013 не установлен где-либо удобно).

Линкер Диагностика

Другой потенциальный подход состоит в том, чтобы включить Линкер / подробный вариант и сравните выходные данные сборок Win32 и Win64. Там будет много вывода, но вы можете использовать «найти» или инструмент сравнения, чтобы найти различия в том, где и как __CIpow а также _pow связаны, которые могут дать вам подсказку. Плохая новость в том, что она, вероятно, не будет указывать непосредственно на причину вашей проблемы. Вам придется вернуться назад к тому, что на самом деле делает Линкер, в сочетании с какой-то детективной работой и экспериментами, чтобы выяснить, что на самом деле происходит.

Ломать перемены

Еще одна возможность, поскольку вы обновляете Visual Studio 2010 до Visual Studio 2013, — это критические изменения. Вам придется работать через список Внушительные изменения, представленные в Visual Studio 2012 и список Разрушительные изменения, представленные в Visual Studio 2013 ищет что-то, что может вызвать симптомы, которые вы получаете.

Несчастные случаи

Если вы этого еще не сделали, убедитесь, что версия вашего решения для Visual Studio 2010 успешно собирается как для Wn32, так и для Win64.

Предполагая, что это так, используйте ваш любимый инструмент сравнения для сравнения файлов .sln и .vcxproj из версий 2010 и 2013. Ищите изменения, которые, кажется, не имеют смысла в текущем контексте. Всегда возможно, что что-то изменилось непреднамеренно.

Наконец, если у вас есть система с установленными Visual Studio 2010 и Visual Studio 2013, вы можете использовать Набор инструментов платформы свойство использовать Visual Studio 2013 для создания проекта с помощью набора инструментов Visual Studio 2010. Если вы обнаружите, что решение успешно компилируется и связывается с использованием набора инструментов 2010 (v100), но не работает с набором инструментов 2013 (v120), это может вам кое-что сказать.