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 likely to result in crashes at runtime. Cheers, Simon
2003年06月17日(火)の20時15分に Simon Marlow 曰く:
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 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? Jens
participants (2)
-
Jens Petersen -
Simon Marlow