Страницы: 1
В продолжение темы, скачав последний 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 файлов должен быть точь-в-точь как в доках.
привет всем.
если кому-то интересно - проблема решена :D.
Поигравшись вдоволь с видами линковки, пообщавшись с народом на irc.mozilla.org(#developers) и попробовав Gecko SDK 1.8 пришел к выводу --- невозможность отвязаться от msvcr71.dll связана с реализацией линковки в Gecko SDK 1.7 :o.
Мои XPCOM компоненты работают с standalone glue линковкой, тогда как по заявлениям разработчиков с irc.mozilla.org не должны, т.к. этот вид линковки предназначен сугубо для embedders :o.
Однако, использование dependent glue линковки (с Gecko SDK 1.7), предназначенной для XPCOM компонент, дает следующий результат - проект не компилится в debug и работает только на браузерах с движком 1.7, хотя по возможности используются FROZEN интерфейсы.
Таким образом dependent glue линковка и выставление ключа /MT и msvcrt.lib в игнорируемые либы - позволяет отвязаться от msvcr71.dll зависимости :D.
В Gecko SDK 1.8 никак проблем с билдом в релиз и дебаг н
…Честно говоря не видел, чтобы в MSDN было написано, что нельзя кидать msvcr*.dll в system32, не дашь ссылочку?
вот ссылка на первоисточник - 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 чтобы осталась тока зав-ть от msvcrt.dll или динамически прилинковаться к бол
…
Здравствуйте,
Написана 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
и получаю
Imag
…Страницы: 1