Ошибка средств компоновщика lnk2005

description	title	ms.date	f1_keywords	helpviewer_keywords	ms.assetid
Learn more about: Linker Tools Error LNK2005	Linker Tools Error LNK2005	11/04/2016	LNK2005	LNK2005	d9587adc-68be-425c-8a30-15dbc86717a4

symbol already defined in object

The symbol symbol was defined more than once.

This error is followed by fatal error LNK1169.

Possible causes and solutions

Generally, this error means you have broken the one definition rule, which allows only one definition for any used template, function, type, or object in a given object file, and only one definition across the entire executable for externally visible objects or functions.

Here are some common causes for this error.

• This error can occur when a header file defines a variable. For example, if you include this header file in more than one source file in your project, an error results:

  // LNK2005_global.h
  int global_int;  // LNK2005

  Possible solutions include:

  • Declare the variable extern in the header file: extern int global_int;, then define it and optionally initialize it in one and only one source file: int global_int = 17;. This variable is now a global that you can use in any source file by declaring it extern, for example, by including the header file. We recommend this solution for variables that must be global, but good software engineering practice minimizes global variables.

  • Declare the variable static: static int static_int = 17;. This restricts the scope of the definition to the current object file, and allows multiple object files to have their own copy of the variable. We don’t recommend you define static variables in header files because of the potential for confusion with global variables. Prefer to move static variable definitions into the source files that use them.

  • Declare the variable selectany: __declspec(selectany) int global_int = 17;. This tells the linker to pick one definition for use by all external references and to discard the rest. This solution is sometimes useful when combining import libraries. Otherwise, we do not recommend it as a way to avoid linker errors.

• This error can occur when a header file defines a function that isn’t inline. If you include this header file in more than one source file, you get multiple definitions of the function in the executable.

  // LNK2005_func.h
  int sample_function(int k) { return 42 * (k % 167); }  // LNK2005

  Possible solutions include:

  • Add the inline keyword to the function:

    // LNK2005_func_inline.h
    inline int sample_function(int k) { return 42 * (k % 167); }

  • Remove the function body from the header file and leave only the declaration, then implement the function in one and only one source file:

    // LNK2005_func_decl.h
    int sample_function(int);

    // LNK2005_func_impl.cpp
    int sample_function(int k) { return 42 * (k % 167); }

• This error can also occur if you define member functions outside the class declaration in a header file:

  // LNK2005_member_outside.h
  class Sample {
  public:
      int sample_function(int);
  };
  int Sample::sample_function(int k) { return 42 * (k % 167); }  // LNK2005

  To fix this issue, move the member function definitions inside the class. Member functions defined inside a class declaration are implicitly inlined.

  // LNK2005_member_inline.h
  class Sample {
  public:
      int sample_function(int k) { return 42 * (k % 167); }
  };

• This error can occur if you link more than one version of the standard library or CRT. For example, if you attempt to link both the retail and debug CRT libraries, or both the static and dynamic versions of a library, or two different versions of a standard library to your executable, this error may be reported many times. To fix this issue, remove all but one copy of each library from the link command. We do not recommend you mix retail and debug libraries, or different versions of a library, in the same executable.

  To tell the linker to use libraries other than the defaults, on the command line, specify the libraries to use, and use the /NODEFAULTLIB option to disable the default libraries. In the IDE, add references to your project to specify the libraries to use, and then open the Property Pages dialog for your project, and in the Linker, Input property page, set either Ignore All Default Libraries, or Ignore Specific Default Libraries properties to disable the default libraries.

• This error can occur if you mix use of static and dynamic libraries when you use the /clr option. For example, this error can occur if you build a DLL for use in your executable that links in the static CRT. To fix this issue, use only static libraries or only dynamic libraries for the entire executable and for any libraries you build to use in the executable.

• This error can occur if the symbol is a packaged function (created by compiling with /Gy) and it was included in more than one file, but was changed between compilations. To fix this issue, recompile all files that include the packaged function.

• This error can occur if the symbol is defined differently in two member objects in different libraries, and both member objects are used. One way to fix this issue when the libraries are statically linked is to use the member object from only one library, and include that library first on the linker command line. To use both symbols, you must create a way to distinguish them. For example, if you can build the libraries from source, you can wrap each library in a unique namespace. Alternatively, you can create a new wrapper library that uses unique names to wrap references to one of the original libraries, link the new library to the original library, then link the executable to your new library instead of the original library.

• This error can occur if an extern const variable is defined twice, and has a different value in each definition. To fix this issue, define the constant only once, or use namespaces or enum class definitions to distinguish the constants.

• This error can occur if you use uuid.lib in combination with other .lib files that define GUIDs (for example, oledb.lib and adsiid.lib). For example:

  oledb.lib(oledb_i.obj) : error LNK2005: _IID_ITransactionObject
  already defined in uuid.lib(go7.obj)
  

  To fix this issue, add /FORCE:MULTIPLE to the linker command line options, and make sure that uuid.lib is the first library referenced.

Ошибка средств компоновщика LNK2005

Символ символа был определен несколько раз.

За этой ошибкой следует Неустранимая ошибка LNK1169.

Возможные причины и решения

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

Ниже приведены некоторые распространенные причины этой ошибки.

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

Ниже представлены возможные решения.

Объявите переменную extern в файле заголовка: extern int global_int; , затем определите ее и при необходимости инициализируйте ее в одном и только одном исходном файле: int global_int = 17; . Теперь эта переменная является глобальной, которую можно использовать в любом исходном файле путем объявления ее extern , например, путем включения файла заголовка. Мы рекомендуем использовать это решение для переменных, которые должны быть глобальными, но хорошей практикой разработки программного обеспечения является сокращение числа глобальных переменных.

Объявите переменную static: static int static_int = 17; . Это ограничивает область определения текущим объектным файлом и позволяет нескольким файловым файлам иметь собственную копию переменной. Не рекомендуется определять статические переменные в файлах заголовков из-за возможности путаницы с глобальными переменными. Предпочитают перемещать определения статических переменных в исходные файлы, которые их используют.

Объявите переменную selectany: __declspec(selectany) int global_int = 17; . Это предписывает компоновщику выбрать одно определение для использования всеми внешними ссылками и отменить остальные. Это решение иногда полезно при объединении библиотек импорта. В противном случае мы не рекомендуем использовать его как способ избежать ошибок компоновщика.

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

Ниже представлены возможные решения.

inline Добавьте ключевое слово в функцию:

Удалите тело функции из файла заголовка и оставьте только объявление, а затем реализуйте функцию в одном и только одном исходном файле:

Эта ошибка также может возникать при определении функций-членов вне объявления класса в файле заголовка:

Чтобы устранить эту проблему, переместите определения функций члена внутри класса. Функции-члены, определенные внутри объявления класса, неявно встроены.

Эта ошибка может возникать при связывании более одной версии стандартной библиотеки или CRT. Например, при попытке связать как розничную, так и отладочную библиотеки CRT либо статическую и динамическую версии библиотеки, или две различные версии стандартной библиотеки для исполняемого файла, эта ошибка может быть сообщена много раз. Чтобы устранить эту проблему, удалите все копии каждой библиотеки, кроме одной, из команды link. В одном исполняемом файле не рекомендуется смешивать библиотеки розничной и отладочной версий, а также разные версии библиотеки.

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

Эта ошибка может возникать, если при использовании параметра /CLR используется сочетание статических и динамических библиотек. Например, эта ошибка может возникнуть при создании библиотеки DLL для использования в исполняемом файле, который ссылается на статическую библиотеку CRT. Чтобы устранить эту проблему, используйте только статические библиотеки или только динамические библиотеки для всего исполняемого файла и для всех библиотек, которые вы создаете для использования в исполняемом файле.

Эта ошибка может возникать, если символ является упакованной функцией (созданной путем компиляции с параметром /Gy) и включен в несколько файлов, но был изменен между компиляциями. Чтобы устранить эту проблему, перекомпилируются все файлы, содержащие упакованную функцию.

Эта ошибка может возникать, если символ определен по-разному в двух объектах-членах в разных библиотеках и используются оба объекта-члена. Один из способов устранить эту проблему, если библиотеки статически связаны, — использовать объект-член только из одной библиотеки и сначала включить эту библиотеку в командную строку компоновщика. Чтобы использовать оба символа, необходимо создать способ их различения. Например, если вы можете построить библиотеки из источника, можно создать оболочку для каждой библиотеки в уникальном пространстве имен. Кроме того, можно создать новую библиотеку оболочек, использующую уникальные имена для переноса ссылок на одну из исходных библиотек, связать новую библиотеку с исходной библиотекой, а затем связать исполняемый объект с новой библиотекой вместо исходной библиотеки.

Эта ошибка может возникать, если extern const переменная определена дважды и имеет другое значение в каждом определении. Чтобы устранить эту проблему, определите константу только один раз или используйте пространства имен или enum class определения для различения констант.

Эта ошибка может возникать, если вы используете UUID. lib в сочетании с другими lib-файлами, определяющими идентификаторы GUID (например, OLEDB. lib и адсиид. lib). Например:

Чтобы устранить эту проблему, добавьте параметр /Force: Multiple в параметры командной строки компоновщика и убедитесь, что UUID. lib является первой библиотекой, на которую имеется ссылка.

Источник

The symbol symbol was defined more than once.

This error is followed by fatal error LNK1169.

Possible causes and solutions

Generally, this error means you have broken the one definition rule, which allows only one definition for any used template, function, type, or object in a given object file, and only one definition across the entire executable for externally visible objects or functions.

Here are some common causes for this error.

This error can occur when a header file defines a variable. For example, if you include this header file in more than one source file in your project, an error results:

Possible solutions include:

Declare the variable extern in the header file: extern int global_int; , then define it and optionally initialize it in one and only one source file: int global_int = 17; . This variable is now a global that you can use in any source file by declaring it extern , for example, by including the header file. We recommend this solution for variables that must be global, but good software engineering practice minimizes global variables.

Declare the variable static: static int static_int = 17; . This restricts the scope of the definition to the current object file, and allows multiple object files to have their own copy of the variable. We don’t recommend you define static variables in header files because of the potential for confusion with global variables. Prefer to move static variable definitions into the source files that use them.

Declare the variable selectany: __declspec(selectany) int global_int = 17; . This tells the linker to pick one definition for use by all external references and to discard the rest. This solution is sometimes useful when combining import libraries. Otherwise, we do not recommend it as a way to avoid linker errors.

This error can occur when a header file defines a function that isn’t inline . If you include this header file in more than one source file, you get multiple definitions of the function in the executable.

Possible solutions include:

Add the inline keyword to the function:

Remove the function body from the header file and leave only the declaration, then implement the function in one and only one source file:

This error can also occur if you define member functions outside the class declaration in a header file:

To fix this issue, move the member function definitions inside the class. Member functions defined inside a class declaration are implicitly inlined.

This error can occur if you link more than one version of the standard library or CRT. For example, if you attempt to link both the retail and debug CRT libraries, or both the static and dynamic versions of a library, or two different versions of a standard library to your executable, this error may be reported many times. To fix this issue, remove all but one copy of each library from the link command. We do not recommend you mix retail and debug libraries, or different versions of a library, in the same executable.

To tell the linker to use libraries other than the defaults, on the command line, specify the libraries to use, and use the /NODEFAULTLIB option to disable the default libraries. In the IDE, add references to your project to specify the libraries to use, and then open the Property Pages dialog for your project, and in the Linker, Input property page, set either Ignore All Default Libraries, or Ignore Specific Default Libraries properties to disable the default libraries.

This error can occur if you mix use of static and dynamic libraries when you use the /clr option. For example, this error can occur if you build a DLL for use in your executable that links in the static CRT. To fix this issue, use only static libraries or only dynamic libraries for the entire executable and for any libraries you build to use in the executable.

This error can occur if the symbol is a packaged function (created by compiling with /Gy) and it was included in more than one file, but was changed between compilations. To fix this issue, recompile all files that include the packaged function.

This error can occur if the symbol is defined differently in two member objects in different libraries, and both member objects are used. One way to fix this issue when the libraries are statically linked is to use the member object from only one library, and include that library first on the linker command line. To use both symbols, you must create a way to distinguish them. For example, if you can build the libraries from source, you can wrap each library in a unique namespace. Alternatively, you can create a new wrapper library that uses unique names to wrap references to one of the original libraries, link the new library to the original library, then link the executable to your new library instead of the original library.

This error can occur if an extern const variable is defined twice, and has a different value in each definition. To fix this issue, define the constant only once, or use namespaces or enum class definitions to distinguish the constants.

Источник

Программа в с++ выдаёт: ошибку обнаружен многократно определенный символ — один или более

Причина, указанная Андреем Котоусовым, возможна, но маловероятна. Те, кто линкует в свой экзешник множество библиотек, не задают таких вопросов. Тем более что в современных библиотеках используются namespace’ы, так что столкновения имен обычно не происходит.

А ВЕРОЯТНАЯ причина вот какая. Вы поместили определение функции (подчеркиваю, именно определение, то есть ТЕЛО функции, а не ее декларацию) в *.h файл. Если этому файлу сделан #include только в ОДИН *.cpp файл, то линковка пройдет и линковщик ни на что не пожалуется. Но если этому файлу сделан #include в два или более *.cpp файлов, то после компиляции в каждом из них возникнет та же самая функция. Линковщик выругается, что видит больше одной функции с одним и тем же прототипом. Решения у этой проблемы два: или перенести тело функции в *.cpp файл, оставив в *.h файле только декларацию (прототип) , или оставить функцию на месте, но объявить ее inline.

Тот же самый эффект может получиться не только с функциями, но и с другими объектами. Скажем, для статических членов класса нужно давать определение в *.срр файле, за пределами определения класса. Но если вы поместите это определение в *.h файл, а затем сделаете этому файлу #include в два или более *.cpp файлов, то линковщик выругается, что он видит несколько определений одного и того же символа.

Кстати, Михаил Левин неправ: чтобы получить такую жалобу от линковщика, совершенно не обязательно сдублировать определение ИМЕННО фунции main. Любая функция проканает.

Источник

main уже определен в source obj

Следующая структура кода:

ArrayStack.h

ArrayStack.cpp

Array.h

Array.cpp

main.cpp

генерирует эти ошибки:

LNK1169 найдено один или несколько найденных символов с несколькими значениями

LNK2005 _main уже определен в Array.obj

В чем проблема? Обратите внимание, что Array.cpp имел int main() , определенный сам по себе, когда он был впервые включен в проект, но больше не имеет его (ни ArrayStack.cpp ). Кроме того, код компилируется просто отлично, когда int main() в main.cpp опущен.

c++ visual-studio linker-errors

1 ответ

2 Решение TobiMcNamobi [2015-12-04 11:28:00]

Сообщение об ошибке означает, что во всех скомпилированных кодах, *.obj файлах, компоновщик находит более одной функции main() . Очевидно, что один из них находится в main.cpp.

Первое решение, которое приходит на ум, как упоминалось в комментариях, состоит в том, чтобы (принудительно) перекомпилировать, как-то удаляя файлы *.obj.

Добрый день, первый раз столкнулся с такой проблемой. При компиляции вылазит следующее для каждого метода:

Собственно сам код:
head.h

head.cpp

main.cpp

1 ответ 1

Включайте через #include заголовочный файл с объявлениями, но не с определениями. Так, как сделали вы, у вас масса определенных (не объявленных, а именно определенных) функций оказывается скомпилированной как в файле head.obj , так и в main.obj , и компоновщик не знает, какой из вариантов выбрать.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками c++ методы компоновщик или задайте свой вопрос.

Похожие

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2019 Stack Exchange Inc; пользовательское содержимое попадает под действие лицензии cc by-sa 4.0 с указанием ссылки на источник. rev 2019.11.15.35459

я в настоящее время застрял на проблему. Он просит, чтобы напечатать ежемесячные продажи для какой-то штукой управления запасами магазина, а затем попросить пользователя ввести число от 1-12, чтобы увидеть в общей сложности в течение определенного месяца.

Я должен предоставить вам, что у меня есть, так как я сделал это в Visual Studio (создан пустой/пустой проект, так что не было ни одного файла «stdafx.h» Должен ли он быть там.?):

И это то, что я до сих пор для main.cpp. Это не полный на данный момент, но я просто хочу убедиться, что я на правильном пути:

Так что я до сих пор должны printMonthlySales для storeMonhtlySales за месяц 1 (январь). «Натянуть» и «CIN >> А» были только там, чтобы предотвратить окно терминала от закрытия автоматически (опять же, я делаю это в Visual Studio).

Тем не менее, я компиляция этих и я получаю две ошибки:

Я озадачен, почему они говорят, что printMonthlySales является «уже определен», так как я не вижу ничего плохого здесь. Просматривая файлы Sales.obj и main.obj ничего не сделал.

2 ответа

Возможно, для Вашего проекта будут необходимы бесплатные векторные карты. На нашем сайте представлены карты для всех стран.

Когда вы включаете файл, он эффективно копировать и вставлять в том числе файл. Все в заголовке теперь часть из файла компилируется. #pragma once , и другие формы включают защитные ограждения предотвратить файл от включения более чем один раз в единица перевода.

единицы перевода составляются отдельно, так что нет никакой преемственности между ними. Там нет никакого способа для B.cpp знать, что a.cpp уже включил данный заголовок. На самом деле, думать о том, как все плохо было бы, если только один файл в большом проекте может #include . C++ был бы отброшен, как пустая трата времени, прежде чем он даже вышел из офиса и в коридоре в Bell Labs.

Так. a.cpp и B.cpp оба включают header.h. Они оба имеют свою собственную копию всего в header.h. Оба скомпилирован просто отлично, но компоновщик не имеет представления о том, что делать с конкурирующими определениями.

extern это обещание, что где-то storeMonthlySales будет определяться так, что компилятор может продолжать делать свою работу. Если он не определен, компоновщик будет жаловаться.

это определение. Он существует только в Sales.cpp. Он может использоваться любой файл, который включает в себя Sales.h

Кстати, следить за using namespace std; . Это заставит вас проблему.

Источник

[{«Product»:{«code»:»SSSHUF»,»label»:»Rational Test RealTime»},»Business Unit»:{«code»:»BU053″,»label»:»Cloud & Data Platform»},»Component»:»—«,»Platform»:[{«code»:»PF033″,»label»:»Windows»}],»Version»:»2003.06.00;2003.06.01;2003.06.12;2003.06.13;2003.06.15;7.0;7.0.0.1;7.0.5″,»Edition»:»»,»Line of Business»:{«code»:»LOB45″,»label»:»Automation»}}]