как избежать "уже определенной ошибки" в C ++ - PullRequest
Новая
       21

как избежать "уже определенной ошибки" в C ++

6 голосов
/ 24 июня 2009

При подключении приложения я получаю ошибки такого типа в проекте MFC VS6: 

msvcrt.lib(MSVCRT.dll) : error LNK2005: _atoi already defined in LIBC.lib(atox.obj)

Я знаю, что это значит (функция существует в 2 разных библиотеках); для ее решения мне нужно исключить одну из 2 библиотек (msvcrt.lib или libc.lib).

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

Есть ли способ сообщить компоновщику, что я хочу использовать функцию _atoi в libc.lib, а не в msvcrt.lib (или наоборот)?

Любая помощь или направление было бы здорово.

Ответы [ 3 ]

11 голосов
/ 24 июня 2009

Эта ошибка, безусловно, означает, что вы связываете две части кода, которые были скомпилированы с использованием различных библиотек времени выполнения. MSVCRT.dll - динамическая версия, а LIBC.lib - статическая. Если вы сделаете это, весь ад вырвется на свободу. Попробуйте найти, какие части вашего кода используют какую версию, и разберитесь в этом.

4 голосов
/ 24 июня 2009

У вас есть конфликт времени выполнения. Использование нескольких библиотек времени выполнения, как правило, плохо.

Вы можете использовать / nodefaultlib: msvcrt (или / nodefaultlib: libc) в параметрах компоновщика, чтобы исключить одно или другое.

Собственно, прежде чем прибегать к этому, проверьте настройки вашего проекта. Если я правильно помню, libc - однопоточная среда выполнения в VS6, а msvcrt - многопоточная среда. Если в вашем решении несколько проектов, убедитесь, что все они используют один или другой.

1 голос
/ 24 июня 2009

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

Выход Build дает что-то вроде этого:

msvcrt.lib (MSVCRT.dll): предупреждение LNK4006: _atoi уже определен в LIBC.lib (atox.obj); второе определение игнорируется

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

Спасибо за другие ответы, но в моем конкретном случае это не подходило.

...