I am building the stub component loader using sample code at
I am getting a dependency on MSVCR71D.DLL under Visual C++ Toolkit 2003
or MSVCR80D.DLL under Visual C++ Standard 2005
for the following functions:
_CppXcptFilter
_dllonexit
_free_dbg
I am not sure if its my environment or possibly an additional compiler
switch (define, option ) that needs to be set in the sample.
Any help would be appreciated.
Please note, neither of these build environments are the standard
compiler for MZILLA_1_8_BRANCH that I used to build the other FF dlls.
XP Home and Professional, Latest Updates
my mozconfig.txt
export BUILDFFICIAL=1
export MZILLAFFICIAL=1
export NMFC=1
ac_add_options
ac_add_options
for the Microsoft Visual C++ Toolkit 2003, the free toolkit, there
are additionally
dev-tech-xpcom mailing list
dev-tech-xpcom (AT) lists (DOT) mozilla.org

gmgj wrote:
I am building the stub component loader using sample code at

I am getting a dependency on MSVCR71D.DLL under Visual C++ Toolkit 2003
or MSVCR80D.DLL under Visual C++ Standard 2005

for the following functions:

_CppXcptFilter
_dllonexit

_free_dbg

I am not sure if its my environment or possibly an additional compiler
switch (define, option ) that needs to be set in the sample.

The sample was designed to be compiled with MSVC6. You can do that even if
the rest of your code needs to be compiled with MSVC7 or 8 or whatever.

Alternatively, you can try to statically link the C runtime. This can
*probably* be accomplished by putting USE_STATIC_LIBS = 1 in the makefile.
However, I've heard that statically linking the CRT doesn't combine well
with linking against libxpcomglue_s.lib (bug is filed, I haven't had time to
investigate it).

Compiling the stub with VC6 is by far the easiest solution, if you have VC6
available.

dev-tech-xpcom mailing list
dev-tech-xpcom (AT) lists (DOT) mozilla.org