RE: [Gtk2hs-users] ghci-5.04.3 and ghc-6.0

What seems to be happening is that the Arrow module in gtk2hs is clashing with the Arrow module in the lang package. As far as I can tell this all looks perfectly normal, so why don't we this kind of problem all the time? What's special about Arrow?
How does it get resolved in the libHS*.a case? How does the system linker resolve the ambiguity when ghci's linker cannot?
The static linker will simply pick the first __stginit_Arrow it finds when searching libraries. In actual fact, you're better off with the linking error, because the static linking behaviour is
2003年06月17日(火)の20時15分に Simon Marlow 曰く: likely to result
in crashes at runtime.
I see, interesting.
In this case gtk2hs.o was generated by ghc-pkg, but naively, can I ask, is it not possible to detect this claiming of module names at buildtime?
Yes, in theory, but it would mean searching the entire search path to find all the .hi files for a module, rather than stopping as soon as you've found one. Cheers, Simon

On Fri, 20 Jun 2003 14:39:43 +0100
"Simon Marlow"
In this case gtk2hs.o was generated by ghc-pkg, but naively, can I ask, is it not possible to detect this claiming of module names at buildtime?
Yes, in theory, but it would mean searching the entire search path to find all the .hi files for a module, rather than stopping as soon as you've found one.
Would it be possible to use the full hierarchical module name? There's a much better chance of them being unique. ie use __stginit_Control_Arrow rather than __stginit_Arrow I *assume* that information is avaliable at compile/build time. Duncan
participants (2)
-
Duncan Coutts
-
Simon Marlow