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)
Здравствуйте, 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
Не ужто баг? ATL проект с MFC + Allow merging of proxy/stub
Не ужто баг очередной?
попробуйте плиз ктото у себя
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
... << Rsdn@Home 1.1.4 beta 1 >>
Re: Не ужто баг? ATL проект с MFC + Allow merging of proxy/s
Здравствуйте, Vi2, Вы писали:
Vi2>Здравствуйте, LaFlour, Вы писали:
LF>>Не ужто баг очередной?
Vi2>Поробуй поиск запрос '"_DllMain@12 already defined in"'
Vi2>Это связано с порядком MFC библиотек или что-то из этой серии. Но никак не с типом проекта.
Никто не просек ситуации. Проект вновь созданный собирается без ошибок. Даже если его сохранить перед сборкой После открытия проекта ЗАНОВО, он билдится с ошибкой!
Как закрытие студии связано с порядком MFC библиотек??
Re: Не ужто баг? ATL проект с MFC + Allow merging of proxy/s
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, LaFlour, Вы писали:
WH>VC++7.1 сделал все как ты описываешь. Проблем нет.
на 4рех машинах проверил в разных местах, на работе, дома — одно и тоже (
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
Здравствуйте, 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