31779 - Cant use debug xpcom with release other libs using it and viceversa

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Suresh Duddi (gone)]

------- Additional Comments From [e-mail] 2000-03-13 
23:10 -------

I think that before Mozilla is released something must be done to nsCOMPtr.h so 
that I can use the Mozilla release libraries with my debug build application. 
And of course the other way around.

Comment 1

[Scott Collins]

A non-debug XPCOM library may work with your developer-specific debug library out 
of the box.  Of course, the debug XPCOM library won't really be a release ... or 
will it?  In either case, you can arbitrarily control debug vs. non-debug 
versions in the face of |nsCOMPtr| by setting |NSCAP_DISABLE_DEBUG_PTR_TYPES| 
uniformly across your builds.  If you need a debug XPCOM library to work with 
release external libraries, just build the debug XPCOM library with this symbol 
defined.  This setting really has no effect on a library that is already release.  
It merely disables one thing about |nsCOMPtr|s that is different in a debug 
build, and makes it be the same as it would be in a release build.  Other 
debugging facilities remain.

So the short answer is: your debug libraries may already work with a release 
XPCOM dll, if they don't, also define |NSCAP_DISABLE_DEBUG_PTR_TYPES| when 
building your library.  Also use this flag when trying to build a debug XPCOM dll 
to work with your release external libraries.  Nothing needs to be done to the 
release XPCOM dll.  Therefore, there's nothing to fix in this bug.  Hope this 
helps.

Comment 2

[Jonas Utterstrom]

I wonder if you have tried the define (NSCAP_FEATURE_TEST_DONTQUERY_CASES or
NSCAP_DISABLE_DEBUG_PTR_TYPES) in an application outside Mozilla? Just try it,
or I can send you a sample. I have never got it to work and I always end up with
linking errors. The only solution I have found so far is to set NS_DEBUG or
DEBUG. Unfortunately, setting NS_DEBUG gives some annoying warnings, see
http://bugzilla.mozilla.org/show_bug.cgi?id=31548. But [e-mail] didn't
like my solution and filed this bug instead. Setting DEBUG is very unattractive
to me since it is widely used as a debugging define in many applications and
also in mine. This makes it hard to combine release and debug builds.

I don't want to make a too big deal of this. I just wanted to remove some
annoying warnings when I use the NS_DEBUG define. I also want to make it easier
for other outsiders to use the Mozilla components from their own applications,
i.e. they should not need to know that the NSCAP_FEATURE_TEST_DONTQUERY_CASES
must be defined.
 

Comment 3

[Scott Collins]

I have not tried it in an application outside of Mozilla.  Please do send me the 
errors.  I really want this to be the solution.  If this solution is broken, I 
will fix it.

Comment 4

[Jonas Utterstrom]

Attachment: Application which uses NSCAP_DISABLE_DEBUG_PTR_TYPES

Comment 5

[Jonas Utterstrom]

I hope you sit in UNIX, since this application uses autoconf.
To compile: 
./configure --with-mozilla={Path to mozilla}
make

The Mozilla build I use is the default debug version. Notice that I don't even
use nsCOMPtr myself in this application. So I can't avoid compilation errors
with refusing to use nsCOMPtr.

Comment 6

[Jonas Utterstrom]

Sorry, it should be 
./configure --with-mozilla={path to Mozilla dist directory}

Comment 7

[Scott Collins]

Pav, can you help me look at this problem on a *nix box of some kind?  We just 
need to look at Jonas' attachments, try to configure and build and examine the 
errors.  Then I can figure out what to do from there.

Comment 8

[Scott Collins]

mass re-assigning to my new bugzilla account

Comment 9

[cls]

Jonas, what compile errors are you getting?  I tried your test case and it
worked fine for me once I fixed the one API change to NS_NewLocalFile().  But
you can only use NSCAP_DISABLE_DEBUG_PTR_TYPES on a non-debug xpcom library so
you'd want to detect that at configure time.  But I still think there needs to
be a better way of letting people mix-n-match debug & non-debug xpcom libs &
components even if that's going back to the idea of having a 'mozilla-config' or
'xpcom-config' script similar to 'glib-config' that will handle these issues for
the user.

Comment 10

[cls]

Shaver, I thought you mentioned a fix for this problem (or a similar one) a
while back on irc.  Did those changes ever make it in?

Comment 11

[cls]

I believe this has been resolved by brendan's checkin of shaver's patch from bug
77112. 
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpcom/base&command=DIFF_FRAMESET&file=nsCOMPtr.h&rev1=1.81&rev2=1.82&root=/cvsroot