GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-01-29T20:04:12Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9907"Unknown PEi386 section name `.text$printf'" error in GHCi on Windows2022-01-29T20:04:12Zmmikolajczyk"Unknown PEi386 section name `.text$printf'" error in GHCi on WindowsI work on a Haskell library interfacing with foreign C++ library. While trying to use it in GHCi on Windows 8.1 64bit, I encountered an error message that said:
```
<loading other libraries>
Loading package library-0.1.0.0 ... <interact...I work on a Haskell library interfacing with foreign C++ library. While trying to use it in GHCi on Windows 8.1 64bit, I encountered an error message that said:
```
<loading other libraries>
Loading package library-0.1.0.0 ... <interactive>: Unknown PEi386 section name `
.text$_ZNSt6vectorIcSaIcEED1Ev' (while processing: c:\path\to\file.o)
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.8.3 for i386-unknown-mingw32):
loadObj "C:\\path\\to\\file.o": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I've prepared a minimal example triggering this bug and attached it to this bug report. On Linux (Arch 64bit), after cabal build and cabal repl it behaves as intended:
```
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) dist/build/cbits/ex.o ... done
final link ... done
[1 of 1] Compiling Example ( Example.hs, interpreted )
Ok, modules loaded: Example.
λ: foo
Test
```
However, on Windows 8.1 it crashes while loading object file:
```
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) dist\build\cbits\ex.o ... ghc.exe: Unknown PEi386 sectio
n name `.text$printf' (while processing: dist\build\cbits\ex.o)
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.8.3 for i386-unknown-mingw32):
loadObj "dist\\build\\cbits\\ex.o": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Crashing in GHCi means that I cannot use it with programs that contain TH splices, what is important for me.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"\"Unknown PEi386 section name `.text$printf'\" error in GHCi on Windows","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":["hvr"],"type":"Bug","description":"I work on a Haskell library interfacing with foreign C++ library. While trying to use it in GHCi on Windows 8.1 64bit, I encountered an error message that said:\r\n\r\n{{{\r\n<loading other libraries>\r\nLoading package library-0.1.0.0 ... <interactive>: Unknown PEi386 section name `\r\n.text$_ZNSt6vectorIcSaIcEED1Ev' (while processing: c:\\path\\to\\file.o)\r\nghc.exe: panic! (the 'impossible' happened)\r\n(GHC version 7.8.3 for i386-unknown-mingw32):\r\nloadObj \"C:\\\\path\\\\to\\\\file.o\": failed\r\n \r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug \r\n}}}\r\n\r\nI've prepared a minimal example triggering this bug and attached it to this bug report. On Linux (Arch 64bit), after cabal build and cabal repl it behaves as intended:\r\n\r\n{{{\r\nGHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading object (static) dist/build/cbits/ex.o ... done\r\nfinal link ... done\r\n[1 of 1] Compiling Example ( Example.hs, interpreted )\r\nOk, modules loaded: Example.\r\nλ: foo\r\nTest\r\n}}}\r\n\r\nHowever, on Windows 8.1 it crashes while loading object file:\r\n\r\n{{{\r\nGHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading object (static) dist\\build\\cbits\\ex.o ... ghc.exe: Unknown PEi386 sectio\r\nn name `.text$printf' (while processing: dist\\build\\cbits\\ex.o)\r\nghc.exe: panic! (the 'impossible' happened)\r\n(GHC version 7.8.3 for i386-unknown-mingw32):\r\nloadObj \"dist\\\\build\\\\cbits\\\\ex.o\": failed\r\n \r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug \r\n}}}\r\n\r\nCrashing in GHCi means that I cannot use it with programs that contain TH splices, what is important for me.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/1407Add the ability to :set -l{foo} in .ghci files2019-07-07T19:13:40ZguestAdd the ability to :set -l{foo} in .ghci filesCurrently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ...Currently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ignored in both 6.4.2 and 6.6.
The only other place it would make sense to pass it would be as something like OPTIONS_GHC, but that results in "unknown flags in {-\# OPTIONS \#-} pragma: -lidn" in 6.4.2 and appears to be silently ignored in 6.6.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Add the ability to :set -l{foo} in .ghci files","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"Currently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ignored in both 6.4.2 and 6.6.\r\n\r\nThe only other place it would make sense to pass it would be as something like OPTIONS_GHC, but that results in \"unknown flags in {-# OPTIONS #-} pragma: -lidn\" in 6.4.2 and appears to be silently ignored in 6.6.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3archblobarchblobhttps://gitlab.haskell.org/ghc/ghc/-/issues/3242GHCi linker does not correctly locate static libraries under Windows2019-07-07T19:04:45Zjeffz1GHCi linker does not correctly locate static libraries under WindowsOn Windows, when attempting to use Hipmunk from ghci, it produces the error:
```
ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
```
To reproduce:
```
cabal install Hipmunk
ghci
:m + Physics.Hipmunk
initChipmunk
```
Pre...On Windows, when attempting to use Hipmunk from ghci, it produces the error:
```
ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
```
To reproduce:
```
cabal install Hipmunk
ghci
:m + Physics.Hipmunk
initChipmunk
```
Presumably this has something to do with there being no libm on Windows.7.10.3Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/9878Static pointers in GHCi cause panic2019-07-07T18:38:39ZKrzysztof GogolewskiStatic pointers in GHCi cause panicI load this module into ghci
```hs
{-# LANGUAGE StaticPointers #-}
module Static where
import GHC.StaticPtr
f = deRefStaticPtr (static True)
```
and get a panic upon evaluating `f`
```
> f
ghc: panic! (the 'impossible' happened)
(G...I load this module into ghci
```hs
{-# LANGUAGE StaticPointers #-}
module Static where
import GHC.StaticPtr
f = deRefStaticPtr (static True)
```
and get a panic upon evaluating `f`
```
> f
ghc: panic! (the 'impossible' happened)
(GHC version 7.9.20141210 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc30486_0/ghc30486_5.so: undefined symbol: Static_sptEntryZC0_closure
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Am I doing static pointers right?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Static pointers in GHCi cause panic","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I load this module into ghci\r\n\r\n{{{#!hs\r\n{-# LANGUAGE StaticPointers #-}\r\nmodule Static where\r\n\r\nimport GHC.StaticPtr\r\nf = deRefStaticPtr (static True)\r\n}}}\r\n\r\nand get a panic upon evaluating `f`\r\n\r\n{{{\r\n> f\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.9.20141210 for x86_64-unknown-linux):\r\n\tLoading temp shared object failed: /tmp/ghc30486_0/ghc30486_5.so: undefined symbol: Static_sptEntryZC0_closure\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nAm I doing static pointers right?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/10375arm: ghci hits an illegal instruction2019-07-07T18:36:20Zerikdarm: ghci hits an illegal instructionSome GHCi tests on arm/linux ie:
```
(cd testsuite ; make TEST="print018 print020 print021 print022 print025")
```
fail, all with the same error:
```
Stderr:
Illegal instruction
```Some GHCi tests on arm/linux ie:
```
(cd testsuite ; make TEST="print018 print020 print021 print022 print025")
```
fail, all with the same error:
```
Stderr:
Illegal instruction
```7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10568Regression from 7.8.4, loading GLUT into GHCI fails on the Mac2019-07-07T18:35:12Zgeorge.colpittsRegression from 7.8.4, loading GLUT into GHCI fails on the Mac```
$ ghci -V
The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612
$ ghci -package GLUT
GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help
<command line>: can't load .so/.DLL for: /Library/Haskel...```
$ ghci -V
The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612
$ ghci -package GLUT
GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help
<command line>: can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13
Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib
Expected in: flat namespace
in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib)
```
This may be related to the fix for #10322 or the underlying problem reported there. The GLUT people are aware of this. They believe it is platform scpecific, a regression from 7.8.4 and probably a ghc issue. See https://github.com/haskell-opengl/GLUT/issues/197.10.3darchondarchonhttps://gitlab.haskell.org/ghc/ghc/-/issues/11003Suggested fix for incorrect directory permissions is wrong2019-07-07T18:32:43ZDavid FeuerSuggested fix for incorrect directory permissions is wrongIf the current directory is group- or world- writable, I get an error
```
*** WARNING: /home/blahblah/src/yproj is writable by someone else, IGNORING!
Suggested fix: execute 'chmod 644 /home/blahblah/src/yproj'
```
This is extremely ba...If the current directory is group- or world- writable, I get an error
```
*** WARNING: /home/blahblah/src/yproj is writable by someone else, IGNORING!
Suggested fix: execute 'chmod 644 /home/blahblah/src/yproj'
```
This is extremely bad advice, because `644 = rw-r--r--`, meaning the directory is not executable, so nothing it contains can be accessed, and a user who's insufficiently familiar with Unix permissions will be very confused. The message should instead suggest `755=rwxr-xr-x`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Suggested fix for incorrect directory permissions is wrong","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If the current directory is group- or world- writable, I get an error\r\n\r\n{{{\r\n*** WARNING: /home/blahblah/src/yproj is writable by someone else, IGNORING!\r\nSuggested fix: execute 'chmod 644 /home/blahblah/src/yproj'\r\n}}}\r\n\r\nThis is extremely bad advice, because `644 = rw-r--r--`, meaning the directory is not executable, so nothing it contains can be accessed, and a user who's insufficiently familiar with Unix permissions will be very confused. The message should instead suggest `755=rwxr-xr-x`.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3