I have a similar issue, I have an extension that depends on other DLLs
that depend on msvcp71.dll and msvcr71.dll.
I build FF the standard way.
I build my extension with lib paths to what I need
ifeq ($(MOZ_DEBUG), 1)
GJCRT = $(GJLIBPATH)msvcrtd.lib
GJCPRT = $(GJLIBPATH)msvcprtd.lib
else
GJCRT = $(GJLIBPATH)msvcrt.lib
GJCPRT = $(GJLIBPATH)msvcprt.lib
endif
# ? neccessary, but for what - doing shared ? see sample in xpcom
EXTRA_DSO_LDOPTS = \
$(DIST)/lib/$(LIB_PREFIX)xpcomglue_s.$(LIB_SUFFIX) \
$(MOZ_COMPONENT_LIBS) \
$(NSPR_LIBS) \
$(GJLIBPATH)sqlite.lib \
$(GJLIBPATH)GMGJUTIL.lib \
$(GJCRT) \
$(GJCPRT) \
$(NULL)
and make sure the dependent DLLs are in the path.
=====================================================================
I have reworked some of this so that I can use the NSPR c calls;
however, I am still looking at what I need to do to remove
the MSVCPRT.lib
Olaf wrote:
> I tried to do the same thing, but I guess it doesn't work. There is a
> component (I believe it is NSPR) that doesn't use the MT setting,
> because it is not in the makefile.
>
> Next to that problem (above is a bug in the bugtracker), the xpidl
> tools don't don't run properly with the static libraries.
>
> Ben Hutchings wrote:
> > Enrico Albonico <[EMAIL PROTECTED]> wrote:
> > > I'm searching for a way to compile mozilla on Windows using the static
> > > version of the C run time library (libcmt.lib, compiler option -MT)
> > > instead of the one which is used normally (msvcrt.lib, with the option
> > > -MD).
> > >
> > > My problem is that I have also other libraries in my project which use
> > > the static version and I cannot change their way of compiling/linking.
> > >
> > > Any Ideas?
> >
> > What makes you think you need to do that? The C library state that I
> > can see generally needs to be shared throughout a program would be the
> > heap, the standard I/O streams and locale information. But I don't
> > think Mozilla uses stdio or C library locale facilities, and it
> > doesn't require you to allocate things that will be freed inside
> > Mozilla (not using direct C library calls, or new and delete, anyway).
> > So I don't think it matters if Mozilla uses another copy of the C
> > library.
> >
> > Ben.
> >
> > --
> > Ben Hutchings
> > Every program is either trivial or else contains at least one bug
_______________________________________________
dev-embedding mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-embedding
