GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-08-25T01:30:04Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16879Hide "Loading package environment" message2019-08-25T01:30:04ZGuillaume BouchardHide "Loading package environment" message# Motivation
#15145 introduced a new log message when a package database is loaded from a file. I'd like a way to hide this message. I tested with `-v0`, without success.
This poses problem in build system, such as bazel / rules_haskel...# Motivation
#15145 introduced a new log message when a package database is loaded from a file. I'd like a way to hide this message. I tested with `-v0`, without success.
This poses problem in build system, such as bazel / rules_haskell, were the output is spammed by this message for each compiler step. See https://github.com/tweag/rules_haskell/issues/969
Example:
```
[nix-shell:~]$ touch .ghc.environment.x86_64-linux-8.6.3
[nix-shell:~]$ ghc
Loaded package environment from /home/guillaume/.ghc.environment.x86_64-linux-8.6.3
ghc: no input files
Usage: For basic information, try the `--help' option.
```
The `Loaded package environment from ...` is annoying.
# Proposal
Apparenly that's a log message with `SevInfo`. I did not found anyway to filter theses log messages. I tried `-v0`, or `-ddump-to-file` without success. `-ddump-json` changes the format of the output, but this stays in stderr.
I'll be happy to know another option to disable that or to have an option to disable log message based on severity.8.10.1Artem PelenitsynArtem Pelenitsynhttps://gitlab.haskell.org/ghc/ghc/-/issues/11587Place shared objects in LIBDIR2020-12-20T18:22:52ZBen GamariPlace shared objects in LIBDIRIf one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program...If one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program start-up. For instance, in the case of a dynamically linked `ghc` executable on Debian 8, compiling a trivial "hello world" application produces over 800 `open` calls, the majority of which originate from the dynamic linker. e.g.,
```
$ strace -f -e open ghc-7.10.3 -c -fforce-recomp Test.hs 2>&1 | grep open
...
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
```
The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness.
Instead of placing each shared library in its own directory, `$LIBDIR/$PKG_KEY/lib$PKG_KEY.so` as we do currently, why not just place them in `$LIBDIR`, e.g. `$LIBDIR/lib$PKG_KEY.so`. This would mean that we need to include only one directory, `$LIBDIR`, in `rpath`.8.10.1