Здравствуйте,

Написана DLL-ка в которой 3 xpcom компоненты.
При написании ориентировался на Windows.

Для разработки использовал MS VS2003 .NET - и никак не могу избавиться от динамической линковки к msvcr71.dll

При попытке изменить Code Generation -> с Multi-threaded Dll на Multi-threaded
получаю следующие ошибки:

ImageShackCom error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
ImageShackCom error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
ImageShackCom error LNK2005: _fclose already defined in LIBCMT.lib(fclose.obj)
ImageShackCom error LNK2005: _sprintf already defined in LIBCMT.lib(sprintf.obj)
ImageShackCom error LNK2005: _strncmp already defined in LIBCMT.lib(strncmp.obj)

после чего в настройках линковщика ставлю игнорить msvcrt.lib

и получаю

ImageShackCom error LNK2019: unresolved external symbol __imp__stat referenced in function _GRE_GetGREPath
ImageShackCom error LNK2001: unresolved external symbol __imp___stat
ImageShackCom error LNK2001: unresolved external symbol __imp__stat
ImageShackCom error LNK2019: unresolved external symbol __imp___fullpath referenced in function _GRE_GetGREPath
ImageShackCom error LNK2019: unresolved external symbol __imp__fgets referenced in function "int __cdecl GRE_GetPathFromConfigFile(char const *,char *)" (?GRE_GetPathFromConfigFile@@YAHPBDPAD@Z)
ImageShackCom error LNK2019: unresolved external symbol __imp__fopen referenced in function "int __cdecl GRE_GetPathFromConfigFile(char const *,char *)" (?GRE_GetPathFromConfigFile@@YAHPBDPAD@Z)

-------------------------------------------------

можно ли как-то решить этот вопрос?
я бы не против распространять с собой msvcr71.dll, но не хотелось бы сорить в папке браузера, а в system32 ее кидать согласно MSDN запрещено.

Кто как решает этот трабл?

вроде как от 2003, как раз в system32 и надо её пихать. Это от 2005й (8.0) mfc и сишный рантайм лежат в папке %windir%\WinSxS, и грузятся по манифесту, который лежит в ресурсах бинарника. И то такой фокус работает тока в >=WinXP. Честно говоря не видел, чтобы в MSDN было написано, что нельзя кидать msvcr*.dll в system32, не дашь ссылочку?
Чтобы не зависить от msvcr71.dll можно прилинковаться статически , честно говоря я не очень догнал, ты хочешь избавиться от msvcr71.dll чтобы осталась тока зав-ть от msvcrt.dll или динамически прилинковаться к более ранней версии msvcr?
и какой у тебя тип проекта?

вот ссылка на первоисточник - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp

Цитата:
"What is the difference between msvcrt.dll and msvcr71.dll?

The msvcrt.dll is now a "known DLL," meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components. An application should use and redistribute msvcr71.dll, and it should avoid placing a copy or using an existing copy of msvcr71.dll in the system directory. Instead, the application should keep a copy of msvcr71.dll in its application directory with the program executable. "

статическая линковка к msvcr71.dll - это моя цель, т.к. я не могу с собой таскать msvcr71.dll.
ты знаешь как к  ней прилинковаться статически если учесть что проект это DLL ?

или динамически прилинковаться к более ранней версии msvcrt, чтобы например компонента могла работать в Win 2000.

Тип проект - DLL, я уже писал об этом.

привет всем.
если кому-то интересно - проблема решена .
Поигравшись вдоволь с видами линковки, пообщавшись с народом на irc.mozilla.org(#developers) и попробовав Gecko SDK 1.8 пришел к выводу --- невозможность отвязаться от msvcr71.dll связана с реализацией линковки в Gecko SDK 1.7 .

Мои XPCOM компоненты работают с standalone glue линковкой, тогда как по заявлениям разработчиков с irc.mozilla.org не должны, т.к. этот вид линковки предназначен сугубо для embedders .

Однако, использование dependent glue линковки (с Gecko SDK 1.7), предназначенной для XPCOM компонент, дает следующий результат - проект не компилится в debug и работает только на браузерах с движком 1.7, хотя по возможности используются FROZEN интерфейсы.

Таким образом dependent glue линковка и выставление ключа /MT и msvcrt.lib в игнорируемые либы - позволяет отвязаться от msvcr71.dll зависимости .

В Gecko SDK 1.8 никак проблем с билдом в релиз и дебаг не выявлено в dependent glue линковке.
Надеюсь, если кто-то сталкнется с такой проблемой - этот пост поможет .

В продолжение темы, скачав последний Gecko SDK для ветви 1.7, т.е. 1.7.13 мне удалось добиться эффекта, которого я не мог добиться с 1.7.10.

НО, пришлось за основу взять Frozen linkage: dependent glue (dependent on xpcom.dll) и при добавлении влага XPCOM_GLUE все билдится.
Естественно, что это получается некий суррогат, но тем не менее теперь XPCOM компонент работает как в браузерах на ядре 1.7, так и на 1.8 и не требуется таскать msvcr71.dll (при выставлении флага /MT и игнорировать msvcrt.lib).

Хочется отметить, что порядок lib файлов должен быть точь-в-точь как в доках.