Don't try to force the calling convension with compiler flags.
This will mismatch too much stuff. You do need to define XP_WIN
in your VC project so that all the calls that use NS_IMETHOD* and
NS_CALLBACK* macros get compiled for the correct conventions. See
nsCOM.h. This has been a problem for various people who create
their own (non-mozilla) project files. I recently checked in an
#ifdef/#error block of code to help people discover this problem
more easily on their own - but that detection code went in after
0.9.3.

see:
http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsCom.h#26

John.


Chris Shen wrote:
> 
> Hi All,
> 
> I recently moved to mfc embedding browser based on mfcembed example
> (mozilla-0-9-3 codebase) on win98 and vc++6.
> I have added some functions into the mfcembed example's browserview
> file, part of code like:
> 
>         nsCOMPtr<nsIDOMDocument> domDocument;
>         aWindow->GetDocument(getter_AddRefs(domDocument));
>         nsCOMPtr<nsIDocument> aDocument =
> do_QueryInterface(domDocument);
>         nsCOMPtr<nsIPrincipal> docPrincipal;
>         rv =  aDocument->GetPrincipal(getter_AddRefs(docPrincipal));
>         if (NS_FAILED(rv))
>         {
>             return;
>         }
> 
>         nsCOMPtr<nsIPresShell> pShell;
>         PRInt32 cnt = aDocument->GetNumberOfShells();
> 
>         if(cnt <= 0)
>         {
>             return;
>         }
>         rv = aDocument->GetShellAt(0, getter_AddRefs(pShell));
>         if(NS_FAILED(rv))
>           return;
> 
> I then used VC++6 IDE to build the release version of the executable
> with debug info option. The application threw the exception at runtime
> as:
> Debug Error.
> Module:
> File: i386\chkesp.c
> Line: 42
> The value of ESP was not properly saved across a function call. This is
> usually a result of calling a function declared with one calling
> convention
> with a function pointer declared with a different calling convention.
> 
> When I debugged into source code, the breakpoint pointed to the line
> "PRInt32 cnt = aDocument->GetNumberOfShells();"
> In fact, I built three versions of mozilla libs/dlls release: one using
> default build options (defined in config\win32), one using debug
> info(set MOZ_PROFILE) and without optimised (changed /O1 to /Od), and
> one with debug info and optimised (/O1).
> The problem remains whenever I linked the application with these
> different version of release built libraries.
> 
> As I refer to MS document, it seems tell me that __stdcall convention
> conflicts with __cdecl (which is default in VC IDE). So, I changed to
> __stdcall option (/Gz) and tried to build the executable but the IDE
> gave a heaps of linkage errors as:
>    Creating library Release/mfcembed.lib and object Release/mfcembed.exp
> 
> BrowserView.obj : error LNK2001: unresolved external symbol
> "__declspec(dllimport) class nsIWeakReference * __stdcall
> NS_GetWeakReference(class nsISupports *,unsigned int *)"
> (__imp_?NS_GetWeakReference@@YGPAVnsIWeakReference@@PAVnsISupports@@PAI@Z)
> 
> BrowserView.obj : error LNK2001: unresolved external symbol "public:
> static void __stdcall nsMemory::Free(void *)" (?Free@nsMemory@@SGXPAX@Z)
> 
> BrowserView.obj : error LNK2001: unresolved external symbol
> "__declspec(dllimport) char * __stdcall ToNewUTF8String(class nsAString
> const &)" (__imp_?ToNewUTF8String@@YGPADABVnsAString@@@Z)
> MfcEmbed.obj : error LNK2001: unresolved external symbol
> "__declspec(dllimport) public: static unsigned int __stdcall
> nsComponentManager::UnregisterFactory(struct nsID const &,class
> nsIFactory *)" (__imp_?UnregisterFactory@nsComponentManager@@SGIABU
> nsID@@PAVnsIFactory@@@Z)
> ... ...
> 
> I assume the mozilla build on win32 uses __stdcall convention (nsCom.h
> macro definintion using __stdcall) but the linkage seems tell me that it
> couldn't find object symbols with __stdcall convention.
> 
> Actually, I have debug build as well. However, the debug version of
> build always throws exception regardless of non-fatal warnings (e.g
> can't find histroy file (db)) or fatal errors. So, it makes me difficult
> to use debug version (refer to bug#94070 in bugzilla).
> 
> Could anyone tell me which bit I should add into my release build to
> make the embedding app work without such exception?
> 
> Thanks in advance

Reply via email to