GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:05:17Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15396-staticlib is broken on GHC 8.4.3 on Linux under certain conditions2019-07-07T18:05:17ZRyan Scott-staticlib is broken on GHC 8.4.3 on Linux under certain conditionsWhen compiling this simple program:
```hs
main = pure ()
```
Using the `-staticlib` flag on GHC 8.4.3 on Linux, it panics if using a certain toolchain:
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Descript...When compiling this simple program:
```hs
main = pure ()
```
Using the `-staticlib` flag on GHC 8.4.3 on Linux, it panics if using a certain toolchain:
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
$ /opt/ghc/8.4.3/bin/ghc -fforce-recomp -staticlib Bug.hs
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug.a ...
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-linux):
Data.Binary.Get.runGet at position 27462987: Invalid archive header end marker
CallStack (from HasCallStack):
error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.5.1:Data.Binary.Get
```
I say "certain toolchain" since I am able to reproduce this issue on Ubuntu 14.04, but not 18.04:
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename: bionic
$ /opt/ghc/8.4.3/bin/ghc -fforce-recomp -staticlib Bug.hs
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug.a ...
```
This issue does not occur on GHC 8.2 and earlier:
```
$ /opt/ghc/8.2.2/bin/ghc -staticlib Bug.hs
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug.a ...
Static archive creation only supported on Darwin/OS X/iOS
```
Commit b8f33bc6b738b0378976e42b79369f0e53b680c7 allowed the use of `-staticlib` on all platforms. angerman, do you know what might be happening here?8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15306First attempt at starting GHCI failed2019-07-07T18:13:21ZDaleBFirst attempt at starting GHCI failed```
PS C:\WINDOWS\system32> ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
ghc.exe: C:\F\G77\lib\libmingw32.a: Not a x86_64 PE+ file.
ghc.exe: getNumberOfSymbols: error whilst reading `CRTglob.o' header in `C:\F\G77\l...```
PS C:\WINDOWS\system32> ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
ghc.exe: C:\F\G77\lib\libmingw32.a: Not a x86_64 PE+ file.
ghc.exe: getNumberOfSymbols: error whilst reading `CRTglob.o' header in `C:\F\G77\lib\libmingw32.a': Unknown COFF_OBJ_TYPE.
ghc.exe: loadArchive: error whilst reading `C:\F\G77\lib\libmingw32.a'
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-mingw32):
loadArchive "C:\\F\\G77\\lib\\libmingw32.a": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15275AArch64 validation fails with many invalid relocations2021-10-08T01:57:13ZBen GamariAArch64 validation fails with many invalid relocationsTest ways requiring the RTS linker (e.g. `ext-interp`) are failing due to the `assert(isInt64(32, addend));` assertion in the `COMPAT_R_AARCH64_ADR_PREL_PG_HI21` of `encodeAddendAarch64`. One such relocation is,
```
RELOCATION RECORDS F...Test ways requiring the RTS linker (e.g. `ext-interp`) are failing due to the `assert(isInt64(32, addend));` assertion in the `COMPAT_R_AARCH64_ADR_PREL_PG_HI21` of `encodeAddendAarch64`. One such relocation is,
```
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
000000000000001c R_AARCH64_ADR_PREL_PG_HI21 stg_upd_frame_info
```
although there are plenty of others.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | angerman |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"AArch64 validation fails with many invalid relocations","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["angerman"],"type":"Bug","description":"Test ways requiring the RTS linker (e.g. `ext-interp`) are failing due to the `assert(isInt64(32, addend));` assertion in the `COMPAT_R_AARCH64_ADR_PREL_PG_HI21` of `encodeAddendAarch64`. One such relocation is,\r\n{{{\r\nRELOCATION RECORDS FOR [.text]:\r\nOFFSET TYPE VALUE\r\n000000000000001c R_AARCH64_ADR_PREL_PG_HI21 stg_upd_frame_info\r\n}}}\r\nalthough there are plenty of others.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14611Support LIBRARY_PATH and LD_LIBRARY_PATH in rts2019-07-07T18:16:18ZTamar ChristinaSupport LIBRARY_PATH and LD_LIBRARY_PATH in rtsTo complement the C compiler's usage of these, the Haskell runtime loader should use `LD_LIBRARY_PATH` to load shared libraries and the linker should use `LIBRARY_PATH` to find libraries.
<details><summary>Trac metadata</summary>
| Tra...To complement the C compiler's usage of these, the Haskell runtime loader should use `LD_LIBRARY_PATH` to load shared libraries and the linker should use `LIBRARY_PATH` to find libraries.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support LIBRARY_PATH and LD_LIBRARY_PATH in rts","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"To complement the C compiler's usage of these, the Haskell runtime loader should use `LD_LIBRARY_PATH` to load shared libraries and the linker should use `LIBRARY_PATH` to find libraries.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/14456Windows runtime linker failure with icuuc2019-07-07T18:16:58ZRyan ScottWindows runtime linker failure with icuucFirst, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2):
```
$ pacman -S mingw-w64-x86_64-icu
```
Now take this file:
```hs
module Main where
import Data.Int
import Foreign
import Foreign.C.String
import Foreign.C.Types
typ...First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2):
```
$ pacman -S mingw-w64-x86_64-icu
```
Now take this file:
```hs
module Main where
import Data.Int
import Foreign
import Foreign.C.String
import Foreign.C.Types
type UErrorCode = CInt
u_ZERO_ERROR :: UErrorCode
u_ZERO_ERROR = 0
foreign import ccall "ucnv_open_58"
c_ucnv_open :: CString -> Ptr UErrorCode -> IO (Ptr ())
foreign import ccall "ucnv_getMaxCharSize_58"
c_ucnv_getMaxCharSize :: Ptr () -> IO Int8
main :: IO ()
main = with u_ZERO_ERROR $ \status -> do
conv <- c_ucnv_open nullPtr status
c_ucnv_getMaxCharSize conv >>= print
```
GHC is able to compile this successfully:
```
$ ghc -licuuc Bug2.hs
[1 of 1] Compiling Main ( Bug2.hs, Bug2.o )
Linking Bug2.exe ...
$ ./Bug2.exe
1
```
But GHCi is unable to accomplish the same thing:
```
$ runghc -licuuc Bug2.hs
ghc.exe: | C:\Users\RyanGlScott\Documents\Hacking\Haskell\Bug2.o: unknown symbol `ucnv_open_58'
Bug2.hs:
```
Phyx- and I discussed this briefly on IRC. He suspected that the fact that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is contributing to the issue.8.6.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/14444Linker limit on OS X Sierra breaks builds for big projects2022-04-27T20:56:31ZdredozubovLinker limit on OS X Sierra breaks builds for big projectsI'm opening a fresh ticket as \@bgamari suggested in #12479. There are few more related closed tickets as well: #12198 and #12588. The issue occurs on projects with a lot of dependencies. There are reports of that happening across variou...I'm opening a fresh ticket as \@bgamari suggested in #12479. There are few more related closed tickets as well: #12198 and #12588. The issue occurs on projects with a lot of dependencies. There are reports of that happening across various projects:
[https://github.com/NixOS/nixpkgs/issues/22810](https://github.com/NixOS/nixpkgs/issues/22810)
[https://github.com/commercialhaskell/stack/issues/2577](https://github.com/commercialhaskell/stack/issues/2577)
I'm still able to reproduce it with 8.2.1 and git HEAD with a work project:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.1 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib, 5): no suitable image found. Did find:
/var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib: malformed mach-o: load commands size (34592) > 32768
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I can't share the sources, but this is a command(generated by stack) that results in this error:
`/Users/dr/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.0.0.2_ghc-8.2.1 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.0.0.2 build lib:projectname exe:projectname --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"`
We're having a chat about this issue with \@bgamari and I'll post some of his input:
```
bgamari: dredozubov, unfortunately this is pretty much a limitation of OS X's linker
bgamari: there's no great solution other than petitioning Apple to lift their arbitrary size limit
bgamari: I've been asking people to open tickets with Apple
bgamari: As they are really the only ones that can really fix this issue
dredozubov: bgamari, do you know if someone did this already?
bgamari: dredozubov, No one has said they have
dredozubov: the other issue with it, I don't how to do a repro case
dredozubov: I can reproduce it on a project with a closed sources and that's it
bgamari: essentially you just need to build a project with enough dependencies
bgamari: the problem is that Apple's linker sets an artificial cap on the number of shared libraries that an object file can load
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Linker limit on OS X Sierra breaks builds for big projects","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm opening a fresh ticket as @bgamari suggested in #12479. There are few more related closed tickets as well: #12198 and #12588. The issue occurs on projects with a lot of dependencies. There are reports of that happening across various projects:\r\n\r\n[https://github.com/NixOS/nixpkgs/issues/22810]\r\n[https://github.com/commercialhaskell/stack/issues/2577]\r\n\r\nI'm still able to reproduce it with 8.2.1 and git HEAD with a work project:\r\n{{{\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.1 for x86_64-apple-darwin):\r\n \tLoading temp shared object failed: dlopen(/var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib, 5): no suitable image found. Did find:\r\n \t/var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib: malformed mach-o: load commands size (34592) > 32768\r\n\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI can't share the sources, but this is a command(generated by stack) that results in this error:\r\n\r\n`/Users/dr/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.0.0.2_ghc-8.2.1 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.0.0.2 build lib:projectname exe:projectname --ghc-options \" -ddump-hi -ddump-to-file -fdiagnostics-color=always\"`\r\n\r\nWe're having a chat about this issue with @bgamari and I'll post some of his input:\r\n{{{\r\n bgamari: dredozubov, unfortunately this is pretty much a limitation of OS X's linker\r\n bgamari: there's no great solution other than petitioning Apple to lift their arbitrary size limit\r\n bgamari: I've been asking people to open tickets with Apple\r\n bgamari: As they are really the only ones that can really fix this issue\r\n dredozubov: bgamari, do you know if someone did this already?\r\n bgamari: dredozubov, No one has said they have\r\n dredozubov: the other issue with it, I don't how to do a repro case\r\n dredozubov: I can reproduce it on a project with a closed sources and that's it\r\n bgamari: essentially you just need to build a project with enough dependencies\r\n bgamari: the problem is that Apple's linker sets an artificial cap on the number of shared libraries that an object file can load\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Moritz AngermannMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/12498Support unconventionally named import libraries2019-07-07T18:26:21ZTamar ChristinaSupport unconventionally named import librariesGHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.
Instead we should look at the presence of ...GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.
Instead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc.
This would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file.
This should add more compatibility with packages on hackage.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support unconventionally named import libraries","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.\r\n\r\nInstead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc.\r\n\r\nThis would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file. \r\n\r\nThis should add more compatibility with packages on hackage.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12218Implement -fexternal-interpreter via static linking2023-06-13T08:00:25ZSimon MarlowImplement -fexternal-interpreter via static linkingAn interesting idea from \@hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new `iserv` binary, and use that as our external interpreter.
This would mean we could support TH ...An interesting idea from \@hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new `iserv` binary, and use that as our external interpreter.
This would mean we could support TH and even limited GHCi without needing a dynamic linker of any kind, which is extremely cool. Apparently this would be useful for AIX where doing dynamic linking is hard.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/11238Redesign the dynamic linking on ELF systems2019-12-02T17:21:22ZPeter Trommlerptrommler@acm.orgRedesign the dynamic linking on ELF systemsThis ticket is to follow up on my comment on #11042.
Let's give dynamic linking on ELF systems a second chance.
I propose the following steps:
1. Collect required features
1. Write up and discuss and agree on a specification
1. Creat...This ticket is to follow up on my comment on #11042.
Let's give dynamic linking on ELF systems a second chance.
I propose the following steps:
1. Collect required features
1. Write up and discuss and agree on a specification
1. Create regression tests for all features
1. Design and implement a new dynamic linker for GHCi
1. (optional) Make it work on Mac OS X too
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Redesign the dynamic linking on ELF systems","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"trommler"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This ticket is to follow up on my comment on #11042.\r\n\r\nLet's give dynamic linking on ELF systems a second chance. \r\n\r\nI propose the following steps:\r\n1. Collect required features\r\n1. Write up and discuss and agree on a specification \r\n1. Create regression tests for all features\r\n1. Design and implement a new dynamic linker for GHCi\r\n1. (optional) Make it work on Mac OS X too","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.org