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
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.
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
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.
Reference from sample.
NS_IMPL_CLASSINFO...
line (in the sample it's line 80)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.
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