Last Comment Bug 299664 - add support for MOZ_USE_NSPR w/ XPCOM_GLUE
: add support for MOZ_USE_NSPR w/ XPCOM_GLUE
has patch with review, fixes embeddin...
: regression
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla1.8beta3
Assigned To: Benjamin Smedberg [:bsmedberg]
: Nathan Froyd [:froydnj]
Depends on:
  Show dependency treegraph
Reported: 2005-07-04 12:17 PDT by timeless
Modified: 2014-06-24 04:30 PDT (History)
4 users (show)
benjamin: blocking1.8b3+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Allow for embedder-defined XPCOM_GLUE_USE_NSPR, rev. 1 (4.09 KB, patch)
2005-07-06 09:51 PDT, Benjamin Smedberg [:bsmedberg]
darin.moz: review+
asa: approval1.8b3+
Details | Diff | Splinter Review

Description User image timeless 2005-07-04 12:17:41 PDT
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 User image Matthew Gertner 2005-07-06 09:14:11 PDT
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 User image Benjamin Smedberg [:bsmedberg] 2005-07-06 09:35:18 PDT
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 User image Benjamin Smedberg [:bsmedberg] 2005-07-06 09:51:08 PDT
Created attachment 188440 [details] [diff] [review]
Allow for embedder-defined XPCOM_GLUE_USE_NSPR, rev. 1
Comment 4 User image Darin Fisher 2005-07-06 10:39:54 PDT

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 User image Benjamin Smedberg [:bsmedberg] 2005-07-07 08:51:51 PDT
Fixed on trunk for 1.8b3
Comment 6 User image Matthew Gertner 2005-07-07 12:39:16 PDT
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 User image Matthew Gertner 2005-07-08 06:55:10 PDT

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
Comment 8 User image Benjamin Smedberg [:bsmedberg] 2005-07-08 07:55:10 PDT
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 User image Darin Fisher 2005-07-08 08:29:23 PDT

Yeah, what Benjamin said.  It's unfortunate that both of these libraries go by
the name XPCOM glue :-/
Comment 10 User image Christian :Biesinger (don't email me, ping me on IRC) 2005-07-08 09:09:24 PDT
does anyone mind if I put a copy of comment 8 into (or, if people prefer, a new page
Comment 11 User image Benjamin Smedberg [:bsmedberg] 2005-07-08 09:16:33 PDT
Please do (probably devmo XPCOM_Glue)
Comment 12 User image Christian :Biesinger (don't email me, ping me on IRC) 2005-07-08 09:39:16 PDT
done, docs at I also tried
to document XPCOM_GLUE_USE_NSPR. I linked to that page from

Note You need to log in before you can comment on or make changes to this bug.