Closed
Bug 211534
Opened 22 years ago
Closed 12 years ago
different sets of symbols are exported in debug builds than optimized builds
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: netscape, Unassigned)
References
Details
Attachments
(1 file)
14.84 KB,
text/plain
|
Details |
It's been a long standing problem that developers cannot build debug components
against an optimized version of xpcom (or vice-versa). Part of the problem is
that we have symbols which are only exported if NS_DEBUG is defined (e.g.
NS_CurrentThread). We should export the same symbols regardless of the build
flags unless the flag enables/disables a set of APIs. We might even want to
consider reducing the API changing flags to only affect the presence of a
library not the contents of it (e.g. --enable-xpcom-obsolete).
Comment 1•22 years ago
|
||
cls: is this about "in-GRE" components or "out-of-GRE" components? none of the
frozen symbols in the xpcom lib change from a debug->opt build, so I'm supposing
that you're talking about this building XPCOM as release and then a debug GRE on
top of it (or vice-versa)?
Comment 2•22 years ago
|
||
we are talking about unfrozen classes and functions.
Reporter | ||
Comment 3•22 years ago
|
||
Here's a diff of the symbol differences between debug & opt xpcom builds.
bsmedberg: I'm talking about just xpcom and xpcom components which are not
built using the exact same build configuration as xpcom. Components in the
GRE, while the de facto example of xpcom components, really do not deserve any
special consideration here.
Frozen-vs-unfrozen really doesn't matter since developers will link against the
library and directly depend upon the symbol of the library regardless of
whether the class is viewed as frozen.
Updated•19 years ago
|
Assignee: dougt → nobody
QA Contact: scc → xpcom
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•