Closed Bug 299664 Opened 15 years ago Closed 15 years ago
add support for MOZ
_USE _NSPR w/ XPCOM _GLUE
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.
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.
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.
Whiteboard: has patch with review, fixes embedding regression
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
Attachment #188440 - Flags: approval1.8b3? → approval1.8b3+
Fixed on trunk for 1.8b3
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta3
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.
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)?
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().
Matthew, 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 http://wiki.mozilla.org/Gecko:SDK (or, if people prefer, a new page http://developer-test.mozilla.org/en/docs/XPCOM_Glue)?
Please do (probably devmo XPCOM_Glue)
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
You need to log in before you can comment on or make changes to this bug.