I am still getting the nsMemory::Free unresolved symbol error.
It is not in xpcomglue.lib, xpcomglue_s.lib, xpcom.lib, or xpcom_core.lib.
Steve
Christian Biesinger wrote:
[cc'ing devmo; quoting entire mail. sorry for replying on top]
Could someone take the time and update
http://developer.mozilla.org/en/docs/XPCOM_Glue with that information?
Benjamin Smedberg wrote:
I link against these files from the FF1.5b2 build ----
*xpcomglue_s.lib xpcomglue.lib nspr4.lib*
There are three ways to compile/link against XPCOM headers:
1) Mozilla internal code
Mozilla internal code defines MOZILLA_INTERNAL_API while compiling and
links against xpcom.lib and xpcom_core.lib. In almost all cases
embedders should *not* use this method.
2) Frozen linkage (dependent on xpcom.dll)
Code which wishes to use only frozen symbols but can tolerate a
load-time dependency on xpcom.dll should link against xpcom.lib and
xpcomglue_s.lib. This is the case for XPCOM components.
3) Frozen linkage (no DLL dependencies)
Embedding code which wishes to use only frozen symbols and cannot
tolerate a load-time dependency on xpcom.dll should define XPCOM_GLUE
while compiling, and link against xpcomglue.lib and *not* against
xpcomglue_s.lib or xpcom.lib. The code must call XPCOMGlueStartup
before using XPCOM APIs. This is only the case in special
circumstances where you need to bootstrap an embedding app by finding
a compatible GRE.
--BDS
P.S. There is really never a situation where you would need to link
against xpcomglue.lib and xpcomglue_s.lib at the same time.
_______________________________________________
Mozilla-xpcom mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-xpcom
