#8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by errge): I've been asked to briefly summarize the issue, since simons didn't write too much about it in the ticket itself. GHC 7.8 uses the xhtml, terminfo and haskeline packages internally. Because of the dynamic ghci transition, the related .so files have to be shipped with the build. By not shipping the devel files (not making the cabal packages visible), we force the distribution vendors to package up these libraries separately and make them available in their repos. Nothing wrong with that of course (they do this for all the other important libraries, like lens and pipes too). The problem is that they can't ship the .so files in the respective packages, because it's usually not allowed for packages to overwrite each other's files in an adhoc manner. So when they build e.g. the xhtml deb or rpm package, they have to make sure that if the resulting .so files have the same name as the ghc shipped ones, then they don't include it in the package. These kind of workarounds seem extremely kludgy and fragile to me. This naming/overwrite issue causes some headaches for NixOS too, just in a slightly different setting. I see two solutions going forward. As nomeata said in comment 16, we can simply ship our .so files in a private directory and make our dynamic programs search there (via RPATH or some other trick). Or we can simply ship these packages with GHC as we ship base, time and so many others. juhpetersen posted a patch for that in comment 14. Alternatively, we can ignore it and just force people to go with the workarounds. I'd prefer not doing that. There were also some discussion on the mailing list about discontinuing the dynamic change after 7.10 and going back to static, which would of course make this go away. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8919#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler