add support for MOZ_USE_NSPR w/ XPCOM_GLUE

RESOLVED FIXED in mozilla1.8beta3



12 years ago
3 years ago


(Reporter: timeless, Assigned: Benjamin Smedberg)



Bug Flags:
blocking1.8b3 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: has patch with review, fixes embedding regression)


(1 attachment)



12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
Created attachment 188440 [details] [diff] [review]
Allow for embedder-defined XPCOM_GLUE_USE_NSPR, rev. 1
Attachment #188440 - Flags: review?(darin)


12 years ago
Attachment #188440 - Flags: review?(darin) → review+


12 years ago
Attachment #188440 - Flags: approval1.8b3?


12 years ago
Flags: blocking1.8b3+
Whiteboard: has patch with review, fixes embedding regression

Comment 4

12 years ago

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


12 years ago
Attachment #188440 - Flags: approval1.8b3? → approval1.8b3+

Comment 5

12 years ago
Fixed on trunk for 1.8b3
Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta3

Comment 6

12 years ago
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

12 years ago

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

12 years ago
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

12 years ago

Yeah, what Benjamin said.  It's unfortunate that both of these libraries go by
the name XPCOM glue :-/
does anyone mind if I put a copy of comment 8 into (or, if people prefer, a new page

Comment 11

12 years ago
Please do (probably devmo XPCOM_Glue)
done, docs at I also tried
to document XPCOM_GLUE_USE_NSPR. I linked to that page from
You need to log in before you can comment on or make changes to this bug.