Dear xmonad list, I would like to report a build problem with xmonad on OS X 10.4 as well as a) a tentative description of the problem; b) a hackish fix which seems to work for me. I. Problem description: The build fails with the following output: vincent$ runhaskell Setup.lhs configure Configuring xmonad-0.4... configure: Dependency base>=2.0: using base-2.0 configure: Dependency X11>=1.2.1: using X11-1.2.2 configure: Dependency X11-extras>=0.4: using X11-extras-0.4 configure: Dependency mtl>=1.0: using mtl-1.0 configure: Dependency unix>=1.0: using unix-1.0 [...] vincent$ runhaskell Setup.lhs build Preprocessing executables for xmonad-0.4... Building xmonad-0.4... [3 of 6] Compiling Config[boot] ( Config.hs-boot, nothing ) [4 of 6] Compiling Operations ( Operations.hs, dist/build/xmonad/xmonad-tmp/Operations.o ) Operations.hs:81:17: Not in scope: `withdrawnState' Operations.hs:190:17: Not in scope: `iconicState' Operations.hs:201:17: Not in scope: `normalState' II. Likely cause: Somehow the above symbols, #define'd in X11R6/include/X11/Xutil.h: /* definitions for initial window state */ #define WithdrawnState 0 /* for windows that are not mapped */ #define NormalState 1 /* most applications want to start this way */ #define IconicState 3 /* application wants to start as an icon */ do not get properly propagated to Operations.hs. I am still sufficiently unfamiliar with the haskell ffi/build chain to figure out where they might get dropped, but at least for me, there seems to be a problem. III. Tentative fix: Replace occurrences of the symbols with the respective hard-coded integer values. About like so: vincent$ darcs diff diff -rN old-xmonad/Operations.hs new-xmonad/Operations.hs 80c80,81 < setWMState w withdrawnState ---
setWMState w 0 --setWMState w withdrawnState
189c190,191 < setWMState w iconicState ---
--setWMState w iconicState setWMState w 3
199c201,202 < setWMState w normalState ---
--setWMState w normalState setWMState w 1
xmonad then builds fine and seems to run happily as well. But obviously, this is not a satisfying solution. I would be grateful for a better one. Kind regards, v.
On Oct 19, 2007, at 11:58 , Vincent Kraeutler wrote:
[4 of 6] Compiling Operations ( Operations.hs, dist/build/xmonad/xmonad-tmp/Operations.o )
Operations.hs:81:17: Not in scope: `withdrawnState'
Operations.hs:190:17: Not in scope: `iconicState'
Operations.hs:201:17: Not in scope: `normalState'
The actual cause is that rebuilding X11-extras without doing a "runhaskell Setup.lhs clean" fails to detect that one of the .hsc files changed, so the new bindings don't actually get compiled in because the corresponding .hs file is not regenerated. This is documented in the X11-extras README. This could arguably be called a cabal bug, but it's not an xmonad or X11-extras bug per se. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
allbery:
On Oct 19, 2007, at 11:58 , Vincent Kraeutler wrote:
[4 of 6] Compiling Operations ( Operations.hs, dist/build/xmonad/xmonad-tmp/Operations.o )
Operations.hs:81:17: Not in scope: `withdrawnState'
Operations.hs:190:17: Not in scope: `iconicState'
Operations.hs:201:17: Not in scope: `normalState'
The actual cause is that rebuilding X11-extras without doing a "runhaskell Setup.lhs clean" fails to detect that one of the .hsc files changed, so the new bindings don't actually get compiled in because the corresponding .hs file is not regenerated. This is documented in the X11-extras README.
This could arguably be called a cabal bug, but it's not an xmonad or X11-extras bug per se.
it's a reported GHC bug. Hopefully fixed soon. I'll put some more reports in about it, since that's 5 or so since the release for the same issue. -- Don
vincent:
Dear xmonad list,
I would like to report a build problem with xmonad on OS X 10.4 as well as a) a tentative description of the problem; b) a hackish fix which seems to work for me.
Can I just confirm this was fixed by runhaskell Setup.lhs clean in the xmonad directory? (And is this bug in ghc's recompilation checker: http://hackage.haskell.org/trac/ghc/ticket/1372 -- Don
Don Stewart wrote:
vincent:
Dear xmonad list,
I would like to report a build problem with xmonad on OS X 10.4 as well as a) a tentative description of the problem; b) a hackish fix which seems to work for me.
Can I just confirm this was fixed by runhaskell Setup.lhs clean in the xmonad directory? (And is this bug in ghc's recompilation checker:
http://hackage.haskell.org/trac/ghc/ticket/1372
-- Don
I am afraid simply running runhaskell Setup.lhs clean did not (directly) fix it for me (after all, my initial attempts had been using a clean X11-extras package, IIRC). Also, the X11-extras package I had (the 0.4 tarball from hackage) did not contain the README file that Brandon hinted at. However, the current darcs version did. So here's what worked for me: 1. pull the newest version of X11-extras from darcs, 2. run autoreconf, as suggested in the README, 3. then do the usual cabal for X11-extras and xmonad. I lack the know-how to be able to tell with certainty whether the issue was indeed due to the problem described in the above ticket. But it seems to be at least closely related. One more suggestion: have you considered doing a qualified import for the X11-extras? It would have certainly led to a more easily debuggable problem. I understand that you're using quite a number of symbols from X11-extras, so that might be a bit more clutter than you're willing to take. But I'd be interested in hearing your opinion. Kind regards, v.
Vincent Kraeutler wrote:
Don Stewart wrote:
vincent:
Dear xmonad list,
I would like to report a build problem with xmonad on OS X 10.4 as well as a) a tentative description of the problem; b) a hackish fix which seems to work for me.
Can I just confirm this was fixed by runhaskell Setup.lhs clean in the xmonad directory? (And is this bug in ghc's recompilation checker:
http://hackage.haskell.org/trac/ghc/ticket/1372
-- Don
I just realize I have misunderstood your question, and I would like to clarify: I don't think the problem was a lack of recompilation of modules in xmonad. Rather, X11-extras failed to export these three required symbols (as I could verify with a bit of nm). So the problem was with X11-extras rather than xmonad. Straight build from the hackage package: X11-extras-0.4.bak vincent$ nm dist/build/libHSX11-extras-0.4.a | grep State X11-extras-0.4.bak vincent$ from darcs, with autoreconf: vincent-kraeutlers-computer-2:~/haskell/X11-extras vincent$ !nm nm dist/build/libHSX11-extras-0.4.a | grep State 00029e48 D _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_iconicState_closure 0001c4f0 T _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_iconicState_info 0001c4e8 t _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_iconicState_info_dsp 00029e58 D _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_normalState_closure 0001c550 T _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_normalState_info 0001c548 t _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_normalState_info_dsp 00029690 D _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_withdrawnState_closure Kind regards, v.
On Saturday 20 October 2007 04:32:06 Vincent Kraeutler wrote:
Vincent Kraeutler wrote:
Don Stewart wrote:
vincent:
Dear xmonad list,
I would like to report a build problem with xmonad on OS X 10.4 as well as a) a tentative description of the problem; b) a hackish fix which seems to work for me.
Can I just confirm this was fixed by runhaskell Setup.lhs clean in the xmonad directory? (And is this bug in ghc's recompilation checker:
http://hackage.haskell.org/trac/ghc/ticket/1372
-- Don
I just realize I have misunderstood your question, and I would like to clarify: I don't think the problem was a lack of recompilation of modules in xmonad. Rather, X11-extras failed to export these three required symbols (as I could verify with a bit of nm). So the problem was with X11-extras rather than xmonad.
Straight build from the hackage package: X11-extras-0.4.bak vincent$ nm dist/build/libHSX11-extras-0.4.a | grep State X11-extras-0.4.bak vincent$
from darcs, with autoreconf: vincent-kraeutlers-computer-2:~/haskell/X11-extras vincent$ !nm nm dist/build/libHSX11-extras-0.4.a | grep State 00029e48 D _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_iconicState_closure 0001c4f0 T _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_iconicState_info 0001c4e8 t _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_iconicState_info_dsp 00029e58 D _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_normalState_closure 0001c550 T _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_normalState_info 0001c548 t _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_normalState_info_dsp 00029690 D _X11zmextraszm0zi4_GraphicsziX11ziXlibziExtras_withdrawnState_closure
Kind regards, v.
These constants were added shortly after the 0.4 release. In general, you should run the darcs version of X11-extras with the darcs version of xmonad. Cheers, Spencer Janssen
Don, Spencer: Spencer Janssen wrote:
On Saturday 20 October 2007 04:32:06 Vincent Kraeutler wrote:
Vincent Kraeutler wrote:
Don Stewart wrote:
Can I just confirm this was fixed by runhaskell Setup.lhs clean in the xmonad directory? (And is this bug in ghc's recompilation checker:
http://hackage.haskell.org/trac/ghc/ticket/1372
-- Don
I just realize I have misunderstood your question, and I would like to clarify: I don't think the problem was a lack of recompilation of modules in xmonad. Rather, X11-extras failed to export these three required symbols (as I could verify with a bit of nm). So the problem was with X11-extras rather than xmonad.
These constants were added shortly after the 0.4 release. In general, you should run the darcs version of X11-extras with the darcs version of xmonad.
Cheers, Spencer Janssen
I believe I can now summarize: My build problem was _not_ due to http://hackage.haskell.org/trac/ghc/ticket/1372 but rather due to a simple mistake of mine: I used xmonad-0.4 from darcs while using the non-darcs X11-extras package. Thank you very much for your help. Kind regards, v.
vincent:
Don, Spencer:
Spencer Janssen wrote:
On Saturday 20 October 2007 04:32:06 Vincent Kraeutler wrote:
Vincent Kraeutler wrote:
Don Stewart wrote:
Can I just confirm this was fixed by runhaskell Setup.lhs clean in the xmonad directory? (And is this bug in ghc's recompilation checker:
http://hackage.haskell.org/trac/ghc/ticket/1372
-- Don
I just realize I have misunderstood your question, and I would like to clarify: I don't think the problem was a lack of recompilation of modules in xmonad. Rather, X11-extras failed to export these three required symbols (as I could verify with a bit of nm). So the problem was with X11-extras rather than xmonad.
These constants were added shortly after the 0.4 release. In general, you should run the darcs version of X11-extras with the darcs version of xmonad.
Cheers, Spencer Janssen
I believe I can now summarize: My build problem was _not_ due to http://hackage.haskell.org/trac/ghc/ticket/1372 but rather due to a simple mistake of mine: I used xmonad-0.4 from darcs while using the non-darcs X11-extras package.
Thank you very much for your help. Kind regards, v.
Spencer, has there been an api change in X11-extras that we depend on? If so, better bump the minor version of X11-extras. -- Don
Don Stewart wrote:
vincent:
[...] I believe I can now summarize: My build problem was _not_ due to http://hackage.haskell.org/trac/ghc/ticket/1372 but rather due to a simple mistake of mine: I used xmonad-0.4 from darcs while using the non-darcs X11-extras package.
Thank you very much for your help. Kind regards, v.
Spencer, has there been an api change in X11-extras that we depend on? If so, better bump the minor version of X11-extras.
-- Don
In the packaged xmonad-0.4, the setWMState operations are carried out using hard-coded integer values, whereas the darcs revision of xmonad relies on symbols exported by the darcs revision of X11-extras (and not by the 0.4 package) i.e.: xmonad-0.4 vincent$ diff Operations.hs ~/haskell/xmonad/Operations.hs 80c80 < setWMState w 0 {-withdrawn-} ---
setWMState w withdrawnState
193c189 < setWMState w 3 --iconic ---
setWMState w iconicState
203c199 < setWMState w 1 --normal ---
setWMState w normalState
241c237 this corresponds exactly to the inverse of my initial fix ;-) I suppose a bumped revision number might indeed be called for. Kind regards, v.
participants (4)
-
Brandon S. Allbery KF8NH -
Don Stewart -
Spencer Janssen -
Vincent Kraeutler