Сборка XPCOM XULRunner 2.0 или более поздних версий - PullRequest
Новая
       64

Сборка XPCOM XULRunner 2.0 или более поздних версий

4 голосов
/ 04 января 2012

Ответы на следующие вопросы:

На какую библиотеку в Gecko 1.9.3 SDK я ссылаюсь, чтобы использовать moz_xmalloc ()?

nsIGenericFactory.h отсутствует в вышеуказанной версии xulrunner-2.0.en-US.win32.sdk

Я могу успешно собрать XPCOM с XULRunner 1.9.2.

Когда я пытаюсь перейти на следующие версии XULRunner (> 1.9), я сталкиваюсь с множеством трудностей. Я получаю сообщения об ошибках типа следующего: 

xpcomglue_s.lib(GenericFactory.obj) : error LNK2001: unresolved external symbol __imp__moz_xmalloc
xpcomglue_s.lib(nsCRTGlue.obj) : error LNK2001: unresolved external symbol __imp__moz_xmalloc
xpcomglue_s.lib(nsTArray.obj) : error LNK2001: unresolved external symbol __imp__moz_xmalloc
xpcomglue_s.lib(nsComponentManagerUtils.obj) : error LNK2001: unresolved external symbol __imp__moz_xmalloc
xpcomglue_s.lib(GenericModule.obj) : error LNK2001: unresolved external symbol __imp__moz_xmalloc
xpcomglue_s.lib(nsISupportsImpl.obj) : error LNK2001: unresolved external symbol __imp__moz_xmalloc

У меня нет четких шагов по миграции для поддержки текущего FireFox.

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

Ответы [ 2 ]

4 голосов
/ 01 апреля 2012

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

xpidl.exe

Я не знаю, изменилось ли это или нет, так что это может быть необязательно.В Gecko 11 нет xpidl.exe. Решение для этого: Филип Чи

Он был заменен скриптом Python.Вы можете продолжить использовать XPIDL из Gecko 7.0 SDK или скомпилировать его из исходного кода, или использовать скрипт Python.

Gecko 7.0 можно загрузить с ftp HERE .Это действительно имеет xpidl.exe.Использование такое же, как в примере

Реализация компонентного модуля

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

Обратите внимание, что nsIGenericFactory.h былудален.Ссылки на nsIGenericFactory.h должны быть заменены на mozilla / ModuleUtils.h

В пример проекта также добавлено #include "nsIClassInfoImpl.h".

Теперь самый большой шаг - изменить NS_IMPL_NSGETMODULE (который также удален) и объявление components, которое используется этим для всей связки, найденной в примере модуля .Вы можете использовать объявление components для справки, я немного помог.

Единственное, что вам не нужно из этого примера, это объявление и использование kSampleCategories.Просто замените его на NULL.По крайней мере, это то, что Бенджамин Смедберг сказал .

Константа kNS_SAMPLE_CID должна быть заменена на kYOUR_CID_CONSTANT.Просто добавьте к имени константы CID.

Эта последняя строка: 

NS_IMPL_MOZILLA192_NSGETMODULE(&kSampleModule)

необходима только для совместимости с Gecko 1.9.Поскольку Firefox 3.5 использует это, я думаю, что я оставлю это.

Реализация компонента (CompImpl.cpp)

Ссылка от sample .

  • Добавьте строку NS_IMPL_CLASSINFO... (в примере это строка 80)
  • Замените NS_IMPL_ISUPPORTS1 на NS_IMPL_ISUPPORTS1_CI

В этом примере есть куча хорошихпримеры того, как использовать значения ввода / вывода.Если вы хотите использовать char *, вам также нужно использовать nsMemory.Я думаю, что для nsStrings это не нужно.

XPCOM Клей без mozalloc

Вот и мы, куча ошибок связывания с __imp__moz_xmalloc.Эта небольшая, действительно трудная для поиска статья помогла избавиться от них:

Начиная с XULRunner 2.0, зависимый от фиксированного связывания клей (xpcomglue_s.lib в Windows, libxpcomglue_s.a в Linux и Mac)зависит от новых непогрешимых процедур выделения памяти (mozalloc).Поскольку эти подпрограммы не существовали до XULRunner 2.0, компоненты XPCOM, которые связываются с зависшим связующим клеем, не будут совместимы с приложениями XULRunner до версии 2.0.

Решение состоит в том, чтобы вместо этого связываться с xpcomglue_s_nomozalloc (xpcomglue_s_nomozalloc.lib в Windows, libxpcomglue_s_nomozalloc.a в Linux и Mac).Эта библиотека является новой в XULRunner 2.0 и идентична xpcomglue_s, за исключением того, что она скомпилирована без mozalloc.Просто измените все ссылки на «xpcomglue_s» в флагах компилятора и компоновщика на «xpcomglue_s_nomozalloc».Результирующие компоненты XPCOM больше не будут зависеть от mozalloc и, следовательно, будут совместимы с приложениями XULRunner до версии 2.0.

Комментарий: вам также может понадобиться построить ваш компонент с флагом MOZ_NO_MOZALLOC (-DMOZ_NO_MOZALLOC)

И, наконец, ошибки нет

1 голос
/ 29 марта 2012

Кажется, это общая проблема. Я вижу, вы уже нашли эту ветку и попробовали стандартный совет, но в интересах других:

определить 'XPCOM_GLUE' в свойстве Определение препроцессора C ++. Будет исправить ошибку компоновки.

Поскольку у вас уже есть это, следующее исправление, которое вы должны попробовать, на самом деле дальше вниз по странице:

Попробуйте определить MOZ_NO_MOZALLOC при компиляции вашего расширения. затем получите DLL, которая использует распределители вашего CRT. (Не забудьте использовать NS_ * распределители для XPCOM-совместимой памяти .)

Вы можете сделать это, добавив #define MOZ_NO_MOZALLOC к содержимому вашего расширения, к configure при сборке XULRunner или к содержимому отдельных файлов, таких как mozilla-config.h.

Хотя, вероятно, вы уже пробовали это, должно решить вашу проблему компоновщика, по крайней мере.

Редактировать: В интересах поставщика щедрых платежей вот совет по решению проблемы __cdecl NS_NewGenericModule2.

...