Не ужто баг очередной?
попробуйте плиз ктото у себя

1)Создаем ATL проект
2)в опциях убираем аттрибуты
3)в опциях включаем поддержку MFC
4)в опциях включаем Allow merging of proxy/stub code

компилим проект. ВСЕ ок
Закрываем проект. Можно выйти из студии.
Открываем опять этот проект, и делаем Rebuild Solution
получаем ошибки

Linking...
mfcs71d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)
mfcs71d.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj); second definition ignored
Creating library Debug/Minibank.lib and object Debug/Minibank.exp
Debug/Minibank.dll : fatal error LNK1169: one or more multiply defined symbols found

Здравствуйте, LaFlour, Вы писали:

Чудеса какие-то рассказываешь.

все нормально редилдится.

и на шестерке и на 7.1

Здравствуйте, LaFlour, Вы писали:

LF>Не ужто баг очередной?

Поробуй поиск запрос '"_DllMain@12 already defined in"'

Это связано с порядком MFC библиотек или что-то из этой серии. Но никак не с типом проекта.

Здравствуйте, Toughpheeckouse, Вы писали:

T>Здравствуйте, LaFlour, Вы писали:
T>Чудеса какие-то рассказываешь.

именно при включении merge proxy/stub

че мне придывать то

Здравствуйте, Vi2, Вы писали:

Vi2>Здравствуйте, LaFlour, Вы писали:

LF>>Не ужто баг очередной?

Vi2>Поробуй поиск запрос '"_DllMain@12 already defined in"'

Vi2>Это связано с порядком MFC библиотек или что-то из этой серии. Но никак не с типом проекта.

Никто не просек ситуации.
Проект вновь созданный собирается без ошибок. Даже если его сохранить перед сборкой
После открытия проекта ЗАНОВО, он билдится с ошибкой!

Как закрытие студии связано с порядком MFC библиотек??

Здравствуйте, LaFlour, Вы писали:

VC++7.1 сделал все как ты описываешь. Проблем нет.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, LaFlour, Вы писали:

WH>VC++7.1 сделал все как ты описываешь. Проблем нет.
на 4рех машинах проверил в разных местах, на работе, дома — одно и тоже (

Здравствуйте, LaFlour, Вы писали:

Сделал ровно, как ты описал.
Бага проявляется.

Студия 7.1.3088.


LF>Не ужто баг очередной?
LF>попробуйте плиз ктото у себя

LF>1)Создаем ATL проект
LF>2)в опциях убираем аттрибуты
LF>3)в опциях включаем поддержку MFC
LF>4)в опциях включаем Allow merging of proxy/stub code

LF>компилим проект. ВСЕ ок
LF>Закрываем проект. Можно выйти из студии.
LF>Открываем опять этот проект, и делаем Rebuild Solution
LF>получаем ошибки

LF>

LF>Linking...
LF>mfcs71d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)
LF>mfcs71d.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj); second definition ignored
LF> Creating library Debug/Minibank.lib and object Debug/Minibank.exp
LF>Debug/Minibank.dll : fatal error LNK1169: one or more multiply defined symbols found

LF>

LF>Не ужто баг очередной?
LF>попробуйте плиз ктото у себя

LF>1)Создаем ATL проект
LF>2)в опциях убираем аттрибуты
LF>3)в опциях включаем поддержку MFC
LF>4)в опциях включаем Allow merging of proxy/stub code

LF>компилим проект. ВСЕ ок
LF>Закрываем проект. Можно выйти из студии.
LF>Открываем опять этот проект, и делаем Rebuild Solution
LF>получаем ошибки

LF>

LF>Linking...
LF>mfcs71d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)
LF>mfcs71d.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj); second definition ignored
LF> Creating library Debug/Minibank.lib and object Debug/Minibank.exp
LF>Debug/Minibank.dll : fatal error LNK1169: one or more multiply defined symbols found

Да, это баг в библиотеке MFC (или в CRT )
По, крайней мере, это справедливо для 7.1, на других версиях не смотрел. Суть проблемы заключается в следующем:
библиотека CRT в числе прочих содержит реализацию функции DllMain в модуле dllmain.c
если проект, использующий CRT, не реализует свою функцию DllMain, то будет использоваться реализация по умолчанию из CRT. Благодаря этому можно, например, создать проект Windows DLL и не реализовывать функцию DllMain.
Если в одном из модулей проекта есть реализация DllMain, то на этапе сборки должна была бы появиться ошибка о "multiply defined symbols DllMain", но ее не возникает благодаря особенностям работы линковщика. Если он обнаруживает повторное определение символа в obj файле, входящем в lib, то пытается полностью исключить этот obj файл со всеми функциями, в нем находящимися. Если это удается сделать, то дальнейшая сборка выполняется нормально. В CRT в модуле dllmain.c кроме реализации DllMain больше нет никаких символов, поэтому если у линковщика уже есть определение для DllMain, то он просто выбрасывает dllmain.obj во время сборки.

Если проект использует MFC, то к нему подключается библиотека mfcs71d.lib (mfcs71.lib), в одном из объектных файлов которой также есть определение для DllMain — dllmodul.cpp. Проблема заключатеся в том, что помимо DllMain в этом же модуле находятся еще несколько функций и поэтому линковщик, встречая повторную реализацию для DllMain, уже не может исключить dllmodul.obj и в итоге появляется ошибка "multiply defined symbols DllMain"
(кстати, это даже в чем то хорошо, потому что если проект бы собрался — то использовалась бы не DllMain из MFC, а заглушка из CRT, что привело бы скроее всего к проблемам)
Интересный побочный эффект этой проблемы связан с тем, что проявляться она будет только при определенном порядке просмотра lib'ов линковщиком. Если первой обрабатывается mfcs71 (а так как правило и просиходит), то встречая позднее DllMain в CRT линковщик спокойно выбрасывает dllmain.obj и сборка завершается без ошибок.
Если же первой будет обрабатываться msvcrt, то встретив позднее DllMain в mfcs71, линковщик уже не сможет исключить dllmodul.obj из процесса сборки и в итоге проект не соберется.

Так происходит в ситуации, которую ты описал. Сразу же после создания проекта ATL+MFC+Merge proxy/stub добавляется модуль "dlldatax.c", который зависит от библиотеки mscvrt, но он обрабатывается последним и при сборке проекта линковщика все проходит на ура. При последующих сборках он уже обрабатывается первым и, как результат, первой обрабатывается mscvrt.lib и появляется ошибка.

Могу посоветовать 2 вещи:
— не использовать merge proxy/stub и не подключать к проекту исходников C
— прописать в Additional Dependencies явно mfcs71d.lib (mfcs71.lib)

Здравствуйте, Ivan, Вы писали:

I>Так происходит в ситуации, которую ты описал. Сразу же после создания проекта ATL+MFC+Merge proxy/stub добавляется модуль "dlldatax.c", который зависит от библиотеки mscvrt, но он обрабатывается последним и при сборке проекта линковщика все проходит на ура. При последующих сборках он уже обрабатывается первым и, как результат, первой обрабатывается mscvrt.lib и появляется ошибка.

А почему собственно порядок меняется? От чего это зависит?

Есть вот такие строчки в проекте, связанные с dlldatax.c и dlldatax.h:

# Begin Source File
SOURCE=.\dlldatax.c
# PROP Exclude_From_Scan -1
# PROP BASE Exclude_From_Build 1
# PROP Exclude_From_Build 1
# End Source File

Может они как-то влияют?

Здравствуйте, Vi2, Вы писали:

Vi2>А почему собственно порядок меняется? От чего это зависит?
имхо, это целиком и полностью зависит от студии. В файле buildlog.html отчетливо видно, что первый раз cl и link вызывается с одним порядком модулей и obj файлов, а второй раз — с другим.
когда link получает список obj файлов — он обрабатывает их по порядку, встречая первым dlldata.obj он видит зависимость от msvcrt и начинает обрабатывать ее первой
т.е. имхо все зависит от строчки вызова link:
если link.exe dlldata.obj x.obj — то будет ошибка, если link.exe x.obj dlldata.obj, то все ok