GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:15:09Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1128The impossible happened, code commented2019-07-07T19:15:09ZhumasectThe impossible happened, code commented```
initializeWorld = (\w -> do
worldSetGravity w 0 (-1.0) 0
worldSetERP w 0.2
worldSetCFM w 1e-5
worldSetContactMaxCorrectingVel w 0.9
worldSetContactSurfaceLayer w 0.001
worldSetAutoDisableFlag w 1),
```
these worldSet\* f...```
initializeWorld = (\w -> do
worldSetGravity w 0 (-1.0) 0
worldSetERP w 0.2
worldSetCFM w 1e-5
worldSetContactMaxCorrectingVel w 0.9
worldSetContactSurfaceLayer w 0.001
worldSetAutoDisableFlag w 1),
```
these worldSet\* functions are unsafe FFI calls. initializeWorld is `Ptr Int -> IO ()`
commenting this prevents this bug. this code is found in a top level declaration:
```
initiailLevel = Level {
...
}
```
of which contains the record for initializeWorld6.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/1098Broken link in the User's Guide2019-07-07T19:15:16Zgn@oglaroon.deBroken link in the User's GuideOn http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html\#hierarchical-modules there's a link called "Haskell Libraries" to a nonexistant page: http://www.haskell.org/\~simonmar/libraries/libraries.html
<details><sum...On http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html\#hierarchical-modules there's a link called "Haskell Libraries" to a nonexistant page: http://www.haskell.org/\~simonmar/libraries/libraries.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Broken link in the User's Guide","status":"New","operating_system":"Multiple","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"On http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#hierarchical-modules there's a link called \"Haskell Libraries\" to a nonexistant page: http://www.haskell.org/~simonmar/libraries/libraries.html","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1096More make boot / make depend problems2019-07-07T19:15:17ZkirstenMore make boot / make depend problemsContinuing my adventure in trying to delete an include file, I ran `make boot` under `compiler/` to update the dependencies there, and eventually got:
```
$ make
make: *** No rule to make target `../includes/StgTicky.h', needed by `stag...Continuing my adventure in trying to delete an include file, I ran `make boot` under `compiler/` to update the dependencies there, and eventually got:
```
$ make
make: *** No rule to make target `../includes/StgTicky.h', needed by `stage1/parser/cutils.o'. Stop.
```
I couldn't find any mention of `StgTicky.h` anywhere under the ghc tree, except in the `.depend` files in `compiler/`. Every time I ran `make depend` or `make boot` in `compiler/` again, it just re-generated that dependency (seemingly out of nowhere). I finally asked Ian and he suggested deleting all the files beginning with `.depend` in `compiler/`, and that worked -- when I ran `make depend` after that, it correctly figured out that there was no dependency on `StgTicky.h` anymore.
I don't understand how the dependency-finding works, but this seems like a bug to me.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"More make boot / make depend problems","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Continuing my adventure in trying to delete an include file, I ran {{{make boot}}} under {{{compiler/}}} to update the dependencies there, and eventually got:\r\n{{{\r\n$ make\r\nmake: *** No rule to make target `../includes/StgTicky.h', needed by `stage1/parser/cutils.o'. Stop.\r\n}}}\r\n\r\nI couldn't find any mention of {{{StgTicky.h}}} anywhere under the ghc tree, except in the {{{.depend}}} files in {{{compiler/}}}. Every time I ran {{{make depend}}} or {{{make boot}}} in {{{compiler/}}} again, it just re-generated that dependency (seemingly out of nowhere). I finally asked Ian and he suggested deleting all the files beginning with {{{.depend}}} in {{{compiler/}}}, and that worked -- when I ran {{{make depend}}} after that, it correctly figured out that there was no dependency on {{{StgTicky.h}}} anymore. \r\n\r\nI don't understand how the dependency-finding works, but this seems like a bug to me.","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1095make boot under includes/ doesn't run make depend2019-07-07T19:15:17Zkirstenmake boot under includes/ doesn't run make dependIn my working copy of GHC, I removed a file from includes/ (`StgTicky.h`) and removed the dependencies on it.
Then I ran `autoreconf`, `./configure`, and finally `make` at the top level.
I got:
```
$ make
make -C utils/mkdependC boot
...In my working copy of GHC, I removed a file from includes/ (`StgTicky.h`) and removed the dependencies on it.
Then I ran `autoreconf`, `./configure`, and finally `make` at the top level.
I got:
```
$ make
make -C utils/mkdependC boot
make[1]: Entering directory `/home/krc/ghc-hacking/utils/mkdependC'
make[1]: Leaving directory `/home/krc/ghc-hacking/utils/mkdependC'
------------------------------------------------------------------------
== make boot -r;
in /home/krc/ghc-hacking/includes
------------------------------------------------------------------------
make[1]: *** No rule to make target `StgTicky.h', needed by `mkDerivedConstants.o'. Stop.
```
I eventually figured out that I needed to run `make depend` in `includes/`, and that updated the dependencies successfully. However, shouldn't `make boot` in `includes` run `make depend`?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"make boot under includes/ doesn't run make depend","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"In my working copy of GHC, I removed a file from includes/ ({{{StgTicky.h}}}) and removed the dependencies on it.\r\n\r\nThen I ran {{{autoreconf}}}, {{{./configure}}}, and finally {{{make}}} at the top level.\r\n\r\nI got:\r\n{{{\r\n$ make\r\nmake -C utils/mkdependC boot\r\nmake[1]: Entering directory `/home/krc/ghc-hacking/utils/mkdependC'\r\nmake[1]: Leaving directory `/home/krc/ghc-hacking/utils/mkdependC'\r\n------------------------------------------------------------------------\r\n== make boot -r;\r\n in /home/krc/ghc-hacking/includes\r\n------------------------------------------------------------------------\r\nmake[1]: *** No rule to make target `StgTicky.h', needed by `mkDerivedConstants.o'. Stop.\r\n}}}\r\n\r\nI eventually figured out that I needed to run {{{make depend}}} in {{{includes/}}}, and that updated the dependencies successfully. However, shouldn't {{{make boot}}} in {{{includes}}} run {{{make depend}}}?","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/853GHC build fails when setting GhcWithInterpreter=No2019-07-07T19:16:37ZJost BertholdGHC build fails when setting GhcWithInterpreter=NoMy GHC build (latest source from darcs) is configured to leave out GHCI, by setting GhcWithInterpreter=No in build.mk.
Since the last update, the GHC build now fails in stage2 with
main/Main.hs:26:0:
> Failed to load interface for \`I...My GHC build (latest source from darcs) is configured to leave out GHCI, by setting GhcWithInterpreter=No in build.mk.
Since the last update, the GHC build now fails in stage2 with
main/Main.hs:26:0:
> Failed to load interface for \`InteractiveUI':
(which is clear, since none of the compiler/ghci/ files have been compiled, as I requested)
The Makefile responsible for the failing command is Makefile.ghcbin, introduced by this patch:
Tue Jul 25 15:01:54 CEST 2006 Simon Marlow \<simonmar\@microsoft.com\>
- Generalise Package Support
This Makefile contains an option -DGHCI responsible for the error. Unfortunately, I have no idea whether just protecting -DGHCI as in the normal Makefile would break something.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC build fails when setting GhcWithInterpreter=No","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My GHC build (latest source from darcs) is configured to leave out GHCI, by setting GhcWithInterpreter=No in build.mk. \r\nSince the last update, the GHC build now fails in stage2 with \r\n\r\nmain/Main.hs:26:0:\r\n Failed to load interface for `InteractiveUI':\r\n\r\n(which is clear, since none of the compiler/ghci/ files have been compiled, as I requested)\r\n\r\nThe Makefile responsible for the failing command is Makefile.ghcbin, introduced by this patch:\r\n\r\nTue Jul 25 15:01:54 CEST 2006 Simon Marlow <simonmar@microsoft.com>\r\n * Generalise Package Support\r\n\r\nThis Makefile contains an option -DGHCI responsible for the error. Unfortunately, I have no idea whether just protecting -DGHCI as in the normal Makefile would break something.","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/764DESTDIR Makefile variable2019-07-07T19:17:05ZguestDESTDIR Makefile variableI'd like the Makefile to have a DESTDIR parameter. This is destined to ease package creation. After the ./configure step the system should be configured to be installed in $(prefix)/bin and other locations. In the "make install" step you...I'd like the Makefile to have a DESTDIR parameter. This is destined to ease package creation. After the ./configure step the system should be configured to be installed in $(prefix)/bin and other locations. In the "make install" step you would specify a different root directory, like "make install DESTDIR=/tmp/fake-rootdir" to get all files copied to /tmp/fake-rootdir$(prefix)/bin (etc) instead of the real destination directories.
This is nothing new. Most famous free software packages provide some way or another of doing this. The DESTDIR name is the typical one in software using the autotools package.
Thanks in advance and keep up the good work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"DESTDIR Makefile variable","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I'd like the Makefile to have a DESTDIR parameter. This is destined to ease package creation. After the ./configure step the system should be configured to be installed in $(prefix)/bin and other locations. In the \"make install\" step you would specify a different root directory, like \"make install DESTDIR=/tmp/fake-rootdir\" to get all files copied to /tmp/fake-rootdir$(prefix)/bin (etc) instead of the real destination directories.\r\n\r\nThis is nothing new. Most famous free software packages provide some way or another of doing this. The DESTDIR name is the typical one in software using the autotools package.\r\n\r\nThanks in advance and keep up the good work.","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/249-caf-all bugs2019-07-07T19:18:50ZSimon Marlow-caf-all bugs```
P.C.Callaghan [p.c.callaghan@durham.ac.uk] submitted
this bug:
I'm trying to use the -caf-all flag with ghc-6.02, in
conjunction with -O
(which means going via C...)
But in a few modules of a large program, the .hc files
contain d...```
P.C.Callaghan [p.c.callaghan@durham.ac.uk] submitted
this bug:
I'm trying to use the -caf-all flag with ghc-6.02, in
conjunction with -O
(which means going via C...)
But in a few modules of a large program, the .hc files
contain duplicate
definitions of "MODsat_CAF_cc_ccs" (where MOD = a
particular module)
I can't see an obvious pattern to the number of
duplications. All the
affected modules use MPCs heavily. It doesn't look like
the duplications
are 1-1 with the instance decls. It only happens on a
few modules out
of many which also use classes heavily.
NB I hand-patched the .hc files by hand, and in the
results, not much of
the dictionary/caf info showed up! Should -auto-dicts work?
```6.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/604Windows installer: use WiX2019-07-07T19:18:56ZSimon MarlowWindows installer: use WiXUse WiX to build windows installers, automate the process as much as possible.Use WiX to build windows installers, automate the process as much as possible.6.6.1