Currently, it is not possible to build a cycle collector participant in non-libxul code because a few necessary functions are not exposed for linking. They're in xpcombase_s but don't get exposed via libxul. The missing exports are: nsCycleCollector_forget nsCycleCollector_suspect nsXPCOMCycleCollectionParticipant::UnmarkPurple nsXPCOMCycleCollectionParticipant::Unroot nsXPCOMCycleCollectionParticipant::Unlink nsXPCOMCycleCollectionParticipant::Root nsXPCOMCycleCollectionParticipant::Traverse

Looks to me like nsXPCOMCycleCollectionParticipant can be moved directly into the glue. We'd have to expose nsCycleCollector_forget and nsCycleCollector_suspect as XPCOM frozen exports, which I think would be ok.

For the record, I developed and tested this on Windows... I'm trying a Linux build with pragma visibility overnight. And I copied/symlinked nsCycleCollectionParticipant.{cpp,h} from xpcom/base to xpcom/glue for the patch. I will just cvs remove/add them for the final commit.

I don't know enough about xpcom guts to say if that patch solves the problem, but the collector's client interface does properly include suspectCurrent, registerRuntime and forgetRuntime.

Well, I know the patch *works* ;-) The decision I need you to comfortable with is exposing NS_CycleCollectorSuspect and NS_CycleCollectorForget as frozen exported functions which are supported "forever", where forever is the life of the 1.9 and 1.9.1 stable branches.

Comment on attachment 273827 [details] [diff] [review] Export cyclecollector necessities, rev. 1 Long term support for these functions is, I think, not a problem: it is not detectable from the caller whether the functions do anything, so in the worst case if you wanted to remove the collector and leave in no-op stubs it would be harmless.

Fixed on trunk.