Building XPCOM XULRunner 2.0 or newer versions

Question

Followup to the following Questions:

What lib in the gecko 1.9.3 SDK do I link against to use moz_xmalloc()?

nsIGenericFactory.h is missing in the above version of xulrunner-2.0.en-US.win32.sdk

I am able to build XPCOM with XULRunner 1.9.2 successfully.

When I try to migrate to the next versions of XULRunner (> 1.9), I am facing lot of difficulties. I am getting Link errors like the following

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

I am not getting clear steps for migration to support for the current FireFox.

I tried the suggestions mentioned in the links. I could not resolve it. Please help me to resolve this issue

Answer 1

I was hopeing someone would provide a full list of what should be changed to get it working on later gecko, but since no one did it, I'll try to do it myself, using this sample I just found.

xpidl.exe

I don't know if this has changed or not, so this might not be necessary. There's no xpidl.exe in Gecko 11. The solution for this from Philip Chee

It has been replaced by a Python script. You can continue using the XPIDL from the Gecko 7.0 SDK, or compile it from source, or use the Python script.

Gecko 7.0 can be downloaded from ftp HERE. It truly has the xpidl.exe. The usage is the same as in the example

Component module implementation

This one seems like it changed a lot. Reference in MDN and another reference (which goes back to the sample provided on top, but explains stuff).

Note that nsIGenericFactory.h has been removed. References to nsIGenericFactory.h should be replaced with mozilla/ModuleUtils.h

In the sample project #include "nsIClassInfoImpl.h" is also added.

Now the biggest step is to change the NS_IMPL_NSGETMODULE (which is also removed), and the declaration of the components, which is used by that to the whole bunch of stuff found in the sample module. You could use the declaration of the components for reference, I did, helps a bit.

The only thing you don't need from that sample is the declaration and usage of kSampleCategories. Just replace it with NULL. At least that's what Benjamin Smedberg said.

The constant kNS_SAMPLE_CID should be replaced with kYOUR_CID_CONSTANT. Just prepend k to you CID constant name.

This last line:

NS_IMPL_MOZILLA192_NSGETMODULE(&kSampleModule)

is only needed for compatibility with Gecko 1.9. Since firefox 3.5 uses that, I'll think I'll leave it.

Component implementation (CompImpl.cpp)

Reference from sample.

• Add the NS_IMPL_CLASSINFO... line (in the sample it's line 80)
• Replace NS_IMPL_ISUPPORTS1 with NS_IMPL_ISUPPORTS1_CI

In this sample there are a bunch of good examples on how to use input / output values. If you want to use char* you also need to use nsMemory. I think for nsStrings this is not necessary.

XPCOM Glue without mozalloc

Here we are again, bunch of linking errors to __imp__moz_xmalloc. This little, really hard to find, article helped get rid of them:

Starting with XULRunner 2.0, the frozen linkage dependent glue (xpcomglue_s.lib on Windows, libxpcomglue_s.a on Linux and Mac) is dependent on the new infallible memory allocation routines (mozalloc). Since these routines didn't exist prior to XULRunner 2.0, XPCOM components that link against the frozen linkage dependent glue will not be compatible with XULRunner applications prior to 2.0.

The solution is to link against xpcomglue_s_nomozalloc instead (xpcomglue_s_nomozalloc.lib on Windows, libxpcomglue_s_nomozalloc.a on Linux and Mac). This library is new in XULRunner 2.0, and it's identical to xpcomglue_s, except that it's compiled without mozalloc. Simply change all references to "xpcomglue_s" in your compiler and linker flags to "xpcomglue_s_nomozalloc". Resulting XPCOM components will no longer have a dependency on mozalloc, and will thus be compatible with XULRunner applications prior to 2.0 as well.

Comment: You might also need to build your component with the MOZ_NO_MOZALLOC flag (-DMOZ_NO_MOZALLOC)

And finally, there is no error

Answer 2

This seems to be a common problem. I see you've already found this thread and tried the standard advice, but for the benefit of others:

define 'XPCOM_GLUE' in C++ Preprocessor Definition property. It will fix the linking error.

Since you already have this in place, the next fix you should try is actually further down the page:

Try defining MOZ_NO_MOZALLOC when compiling your extension, you will then get a DLL that uses your CRT's allocators. (Don't forget to use the NS_* allocators for XPCOM-compatible memory.)

You can do this by adding #define MOZ_NO_MOZALLOC to the contents of your extension, to configure when you build XULRunner, or in the contents of individual files such as your mozilla-config.h.

Although it's exceedingly likely you've tried this already, it should resolve your linker issue, at least.

Edit: For the benefit of the bounty provider, here's advice to resolve the __cdecl NS_NewGenericModule2 issue.