#10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): OK thanks. I made a little progress in understanding what's going on here. The `-framework` option does work when building an executable. See the handling of `framework_opts` in `DriverPipeline.linkBinary'`. However building a shared library is done by `SysTools.linkDynLib`. This function uses `ldInputs dflags`, which is initially set by ghc's `-lfoo` flag, to link against ordinary shared libraries, but it does no processing of framework options. So, that would seem to be a bug in ghc. I still don't understand why Cabal doesn't actually pass ghc `-framework GLUT` automatically when `GLUT.cabal` contains `frameworks: GLUT`. There's code that clearly intends to do so, see https://github.com/ghc/packages- Cabal/blob/master/Cabal/Distribution/Simple/Program/GHC.hs#L348. I think the reason this all used to work in 7.8 is that Cabal records the fact that the GLUT package needs the GLUT framework in the package registration, and ghci checks this and loads the GLUT framework before loading the GLUT package. However since #8935 that no longer makes the framework visible to the package. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10568#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler