299664 - add support for MOZ_USE_NSPR w/ XPCOM_GLUE

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[timeless]

this is a 18b3 regression.

we have a library whose only purpose in life is to be threadsafe. it has one
other requirement which is that it *easily* build against any mozilla from 1.7
through the present. this broke w/ 1.8b3 because threadsafe support had to be
torn out from xpcom_glue. to simplify our life (because the string library among
other things kept moving around) we chose to link against xpcom glue which was
supposed to not change and not move and stuff. while i am slowly growing magical
incantations to pick out random libraries, it's a royal pain when everyone keeps
changing where things live.

note that for whatever reason we already link against nspr, so that requirement
is not at all a concern for us, and adding a define that doesn't hurt old
versions of mozilla does not bother me at all.

bsmedberg says he can fix this, we unfortunately planned to pull in 18b3 and
this would be a blocker for us.

i'd fix this myself but my apartment is being smoked by a bbq and i can't breath
here long enough to bang my head on it for the fourth.

Comment 1

[Matthew Gertner]

Same here. We have a set of standalone components that are linked using
XPCOM_GLUE. We also use NSPR extensively, including the thread-safety macros in
nsISupportsImpl.h. We can probably patch 1.8b3 to keep our heads above water but
we really need the proposed MOZ_USE_NSPR support.

BTW: Is there any discussion available online about the removal of threadsafe
support from XPCOM_GLUE? I poked around but couldn't find anything.

Comment 2

[Benjamin Smedberg]

The original discussion took place in bug 298047. In almost every case I can't
see why xpcom *components* would need to link against the XPCOM glue, since you
know that the XPCOM DLL is already loaded. But I will provide a #define for you
anyway; I intend to call it XPCOM_GLUE_USE_NSPR.

Comment 3

[Benjamin Smedberg]

Attachment: Allow for embedder-defined XPCOM_GLUE_USE_NSPR, rev. 1

Comment 4

[Darin Fisher]

Matthew:

Try linking against xpcomglue_s instead of xpcomglue.  Here's what the library
list usually looks like with MSVC:

  xpcomglue_s.lib xpcom.lib nspr4.lib plds4.lib plc4.lib

Comment 5

[Benjamin Smedberg]

Fixed on trunk for 1.8b3

Comment 6

[Matthew Gertner]

Thanks for the fix, Benjamin.

Regarding glue vs. no glue: my admittedly hazy understanding is the glue has the
main advantage that you can be fairly confident that the interfaces you are
linking with isn't going to change. Also, there is the isolation from the
particular version(s) of Gecko that are running. The flip side is that you get
all that extra baggage. I'm not crazy about static linking in general for that
reason (isn't that why God invented DLLs? :-) so I'm leaning towards Benjamin's
approach. Would love to get an expert opinion on this, though.

xpcomglue.lib vs. xpcomglue_s.lib: my initial assumption was that the former is
an import library but it looks pretty big for that. Is it for embedding or
something? I'm just curious.

Thanks again for your input. We're still getting up to speed and this is very,
very helpful.

Comment 7

[Matthew Gertner]

Darin,

Another question: when linking with xpcomglue_s.lib, why link with xpcom.lib?
Doesn't that kind of defeat the purpose (i.e. of staying independent of the
XPCOM DLLs)?

Comment 8

[Benjamin Smedberg]

Matthew, you can safely link against the frozen symbols of xpcom.dll
(xpcom.lib). There are two different linking strategies here:

1) If you don't mind a runtime dependency on xpcom.dll (and NSPR), you can link
against xpcomglue_s.lib (the "dependent" glue) and xpcom.lib. This ensures that
you are only using frozen symbols from xpcom.dll.

2) If you don't want a runtime dependency on xpcom.dll (a special case mainly
needed by certain kinds of embedding apps that need to dynamically find a GRE to
bootstrap their embedding), you want to compile your code with XPCOM_GLUE, link
against xpcomglue.lib (called the "standalone" glue), and make sure you have
called XPCOMGlueStartup().

Comment 9

[Darin Fisher]

Matthew,

Yeah, what Benjamin said.  It's unfortunate that both of these libraries go by
the name XPCOM glue :-/

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

does anyone mind if I put a copy of comment 8 into
http://wiki.mozilla.org/Gecko:SDK (or, if people prefer, a new page
http://developer-test.mozilla.org/en/docs/XPCOM_Glue)?

Comment 11

[Benjamin Smedberg]

Please do (probably devmo XPCOM_Glue)

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

done, docs at http://developer-test.mozilla.org/en/docs/XPCOM_Glue. I also tried
to document XPCOM_GLUE_USE_NSPR. I linked to that page from
http://developer-test.mozilla.org/en/docs/XPCOM#Articles_.26_Tutorials