GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:13:36Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15256GHCi check .ghci permission on WSL(Linux on Windows)2019-07-07T18:13:36ZyongjoonGHCi check .ghci permission on WSL(Linux on Windows)GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.
You can reproduce this problem from 8.2.2.\~8.4.3 of GHC-WSL(https://launchpad.net/\~hvr/+archive/ubuntu/ghc-wsl).
I think GHCi of WSL would ...GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.
You can reproduce this problem from 8.2.2.\~8.4.3 of GHC-WSL(https://launchpad.net/\~hvr/+archive/ubuntu/ghc-wsl).
I think GHCi of WSL would skip .ghci permission check.
I used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem.
However, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check.
As you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777.
Therefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console.
P.S.
Is there any bug-report place only for GHC-WSL? I couldn't find it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi check .ghci permission on WSL(Linux on Windows)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.\r\nYou can reproduce this problem from 8.2.2.~8.4.3 of GHC-WSL(https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl).\r\n\r\nI think GHCi of WSL would skip .ghci permission check.\r\n\r\nI used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem.\r\n\r\nHowever, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check.\r\nAs you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777.\r\n\r\nTherefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console.\r\n\r\nP.S.\r\nIs there any bug-report place only for GHC-WSL? I couldn't find it.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15397Linking Issue with libffi on Ubuntu and Fedora with Provided Bindists2024-01-19T11:48:16ZAra AdkinsLinking Issue with libffi on Ubuntu and Fedora with Provided BindistsIt appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. ...It appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. This means that at runtime, despite the systems in question having a copy of `libffi.so.6`, the binary can't find the correct shared library to link against.
This does not happen on Arch Linux or Gentoo, as `/usr/lib` or `/usr/lib64` are included in their linker invocations respectively, allowing the linker to pick up the correct version of the dependency.
You can reproduce the issue quickly by cloning [Luna Core](https://github.com/luna/luna-core) and executing the following commands. I suggest doing this on an Ubuntu or Fedora system as I know it fails on those two distros.
```
stack build luna-shell --fast
stack exec luna
```
You should see something along the lines of the following.
```
error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory
```
In essence, the reproduction steps are as follows:
1. Create a project depending on libffi using ghc-8.4.2
1. Build the project
1. Execute it
The *expected* result is that the binary links against the system copy of `libffi.so.6`, rather than the `libffi.so.7` provided in the ghc distribution.
I can't guarantee that Ubuntu and Fedora are the only affected systems, but I know that Arch Linux and Gentoo were both fine with the provided bindists. All tested systems were x64, so I cannot confirm if the issue affects x86 bindists.
The actual symptom appears to be a result of the linker never being given the path to the system library directory (e.g. `/usr/lib` or `/usr/lib64`), whereas on Arch and Gentoo, the linkline does contain that directory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Linking Issue on Ubuntu and Fedora with Provided Bindists (GHC-8.4.2)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. This means that at runtime, despite the systems in question having a copy of `libffi.so.6`, the binary can't find the correct shared library to link against.\r\n\r\nThis does not happen on Arch Linux or Gentoo, as `/usr/lib` or `/usr/lib64` are included in their linker invocations respectively, allowing the linker to pick up the correct version of the dependency.\r\n\r\nYou can reproduce the issue quickly by cloning [https://github.com/luna/luna-core Luna Core] and executing the following commands. I suggest doing this on an Ubuntu or Fedora system as I know it fails on those two distros.\r\n\r\n{{{\r\nstack build luna-shell --fast\r\nstack exec luna\r\n}}}\r\n\r\nYou should see something along the lines of the following. \r\n\r\n{{{\r\nerror while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory\r\n}}}\r\n\r\nIn essence, the reproduction steps are as follows:\r\n\r\n1. Create a project depending on libffi using ghc-8.4.2\r\n2. Build the project\r\n3. Execute it\r\n\r\n\r\nThe ''expected'' result is that the binary links against the system copy of `libffi.so.6`, rather than the `libffi.so.7` provided in the ghc distribution. \r\n\r\nI can't guarantee that Ubuntu and Fedora are the only affected systems, but I know that Arch Linux and Gentoo were both fine with the provided bindists. All tested systems were x64, so I cannot confirm if the issue affects x86 bindists. \r\n\r\nThe actual symptom appears to be a result of the linker never being given the path to the system library directory (e.g. `/usr/lib` or `/usr/lib64`), whereas on Arch and Gentoo, the linkline does contain that directory. ","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4