It might help you to look at how I set the Mozilla compile flags for my
project. I had to deal with essentially the same problem:
http://cvs.gnome.org/lxr/source/nautilus/configure.in#361
The issue (as scc said) is that you need to compile everything with the
same flags. The tiny bit of evil described in the url above figures
that out from a binary mozilla installation - say, for example RPMS of
mozilla on Linux.
-re
Scott Collins wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This problem is covered specifically in the nsCOMPtr user's guide.
>
> See
>
> <http://www.mozilla.org/projects/xpcom/nsCOMPtr.html
> #NSCAP_FEATURE_DEBUG_PTR_TYPES>
>
> Essentially, the entire app must be compiled with the same setting of
> the build flag |NSCAP_FEATURE_DEBUG_PTR_TYPES|. By _default_ this is
> controlled by the debug flags. So, unless you take specific action,
> the bad behavior you have experienced is the typical result of mixing
> debug and non-debug pieces together in your build. In particular, a
> debug build of the XPCOM library mixed with non-debug builds of any
> other components will cause link problems. You can have a
> link-compatible debug build of XPCOM by defining
> |NSCAP_DISABLE_DEBUG_PTR_TYPES|.
>
> There have been bug reports against this in the past, and there are
> lengthy explanations in some of them. I would cite one but bugzilla
> is currently backing up so I'll have to search later.
>
> Yes, the thing you are doing now is a hack. You've made a function
> with the right name available, but it's unrelated to the actual
> inheritance of |nsCOMPtr| in the place where you are wanting it. As
> it turns out ... everything is the right shape, and your app works,
> but that's really just a coincidence ;-) The real answer is to fix
> your flags so |NSCAP_FEATURE_DEBUG_PTR_TYPES| is consistent.
>
> Hope this helps,
>
