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)

defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: netscape, Unassigned)

References

Details

Attachments

(1 file)

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).
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)?
we are talking about unfrozen classes and functions.
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.
Blocks: 214703
Assignee: dougt → nobody
QA Contact: scc → xpcom
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.

Attachment

General

Created:
Updated:
Size: