+/* NOTE [io-manager-ghci]
+
+ When GHCi loads the base package, it gets another copy of the CAFs
+ in GHC.Conc that record the IO manager's ThreadId, and the blocking
+ queues, so we get another IO manager. This is bad enough, but what
+ is worse is that GHCi by default reverts all CAFs on every :load,
+ so we'll get *another* IO manager thread (and an associated pipe)
+ every time the user does :load. Miraculously, this actually
+ manages to just about work in GHC 6.10 and earlier, but broke when
+ I tried to fix #1185 (restarting the IO manager after a fork()).
+
+ To work around it and ensure that we only have a single IO manager,
+ we map the CAFs in the dynamically-loaded GHC.Conc to the
+ statically-linked GHC.Conc. This is an ugly hack, but it's the
+ least ugly hack that I could think of (SDM 3/11/2009)
+*/
+
+#define RTS_GHC_CONC_SYMBOLS \
+ SymI_NeedsProto(base_GHCziConc_pendingDelays_closure) \
+ SymI_NeedsProto(base_GHCziConc_ioManagerThread_closure)
+
+#ifdef mingw32_HOST_OS
+#define RTS_GHC_CONC_OS_SYMBOLS /* empty */
+#else
+#define RTS_GHC_CONC_OS_SYMBOLS \
+ SymI_NeedsProto(base_GHCziConc_pendingEvents_closure) \
+ SymI_NeedsProto(base_GHCziConc_prodding_closure) \
+ SymI_NeedsProto(base_GHCziConc_sync_closure) \
+ SymI_NeedsProto(base_GHCziConc_stick_closure)
+#endif
+