[GHC] #7478: setSessionDynFlags does not always work

[GHC]

#7478: setSessionDynFlags does not always work
-------------------------------------+-------------------------------------
        Reporter:  edsko             |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:  7.12.1
       Component:  Compiler          |                 Version:  7.7
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:  ghc-
 Related Tickets:                    |  api/T7478
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by bherzog):

 I observe the same problem as [comment:8 thoughtpolice], also on a 32
 bit Linux system (debian Wheezy), but with ghc master
 7b042d5adabdb0fc06286db1a7f9cbf1e9fd1fbf. I have analysed it a bit and I
 think I have a solution or a least a work-around.

 On my system, the flags returned by `getSessionDynFlags` in `T7478.hs` are
 inconsistent with regard to dynamic vs. static linking. The `ways` list is
 empty, so in particular does not contain `WayDyn`, but at the same time,
 `Opt_Static` is not in `generalFlags`. This state of the flags is a bit
 contradictory, because AFAICT, there's some code that only looks at the
 presence of `WayDyn` when deciding whether a static or dynamic build has
 been requested while some other code only looks at `Opt_Static`. A missing
 `WayDyn` means to link statically, whereas a missing `Opt_Static` means
 linking dynamically.

 So the code expects this to be more consistent, which is also apparent
 from the fact that the `updateWays` function sets/unsets `Opt_Static`
 depending on the absence/presence of `WayDyn`.

 A workaround that works for me is to extend `defaultDynFlags` so that it
 applies `updateWays` to the `DynFlags` value it creates.

 I'm not sure that's the correct solution, though.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler