GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-12-12T20:03:31Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4374Remove in-tree gmp2022-12-12T20:03:31ZIan Lynagh <igloo@earth.li>Remove in-tree gmpWe already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.
I'm assuming installin...We already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.
I'm assuming installing GMP on other non-Windows OSes is not painful. We probably want to point to a framework for OS X users to use.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove in-tree gmp","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"We already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.\r\n\r\nI'm assuming installing GMP on other non-Windows OSes is not painful. We probably want to point to a framework for OS X users to use.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4022GHC Bindist is Broken on FreeBSD/amd642021-12-03T17:50:15ZpgjGHC Bindist is Broken on FreeBSD/amd64After correcting the name of the FreeBSD/amd64 platform in `PlatformSupportsSharedLibs` it turned out that shared libraries do not build on that platform at all. Log shows that the problem is with the integer-gmp library where the source...After correcting the name of the FreeBSD/amd64 platform in `PlatformSupportsSharedLibs` it turned out that shared libraries do not build on that platform at all. Log shows that the problem is with the integer-gmp library where the sources are not compiled with the `-fPIC` flag.
Excerpt from the build log:
```
...
"inplace/bin/ghc-stage1" libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o `/usr/bin/find libraries/integer-gmp/dist-install/build -name "*_stub.dyn_o" -print` -shared -dynamic -dynload deploy -dylib-install-name /usr/local/lib/ghc-6.13.20100427/`basename "libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so" | sed 's/^libHS//;s/[-]ghc.*//'`/`basename "libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so"` -no-auto-link-packages -packageghc-prim-0.2.0.0 -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value
...
```
According to Simon Marlow, it looks like it is building the in-tree gmp library rather than using a local one, and perhaps there is no shared version, so `gcc` picks up the static one and complains. There should be a shared gmp library when shared Haskell libraries are being built.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.13 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"GHC Bindist is Broken on FreeBSD/amd64","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"pgj"},"version":"6.13","keywords":["FreeBSD,","GMP,integer-gmp,","sharedlibs","x86_64,"],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"After correcting the name of the FreeBSD/amd64 platform in `PlatformSupportsSharedLibs` it turned out that shared libraries do not build on that platform at all. Log shows that the problem is with the integer-gmp library where the sources are not compiled with the `-fPIC` flag.\r\n\r\nExcerpt from the build log:\r\n\r\n{{{\r\n...\r\n\"inplace/bin/ghc-stage1\" libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o `/usr/bin/find libraries/integer-gmp/dist-install/build -name \"*_stub.dyn_o\" -print` -shared -dynamic -dynload deploy -dylib-install-name /usr/local/lib/ghc-6.13.20100427/`basename \"libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so\" | sed 's/^libHS//;s/[-]ghc.*//'`/`basename \"libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so\"` -no-auto-link-packages -packageghc-prim-0.2.0.0 -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so\r\n/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC\r\nlibraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value\r\n...\r\n}}}\r\n\r\nAccording to Simon Marlow, it looks like it is building the in-tree gmp library rather than using a local one, and perhaps there is no shared version, so `gcc` picks up the static one and complains. There should be a shared gmp library when shared Haskell libraries are being built.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1pgjpgjhttps://gitlab.haskell.org/ghc/ghc/-/issues/8156amd64 + in-tree gmp build broken2020-02-07T13:07:19Zerrgeamd64 + in-tree gmp build brokenCurrently, the GHC build system has an in-tree GMP. This GMP seems to
be used only if there is no usable GMP found on the system and the
user didn't provide one using configure flags.
When we build GHC using an external shared version o...Currently, the GHC build system has an in-tree GMP. This GMP seems to
be used only if there is no usable GMP found on the system and the
user didn't provide one using configure flags.
When we build GHC using an external shared version of GMP, the
resulting GHC is dynamically linked against GMP and also the
generated programs are linked dynamically against GMP.
When the in-tree GMP is used, it is built statically, even if the GHC
we are building is shared GHC on GNU/Linux. This feature is currently
broken on amd64 (#4366, #4022), but is working currently
very well on Linux i686.
Apart from the breakage this setting is very flexible and I'd be very
happy if it were possible to keep it, in spite of removeal requests
like #4374.
When there is a system GMP, nothing would change, this is the most
typical usage, e.g. distributions are all building this way.
On the other hand, if the user removes his GMP (maybe we should
provide an option to explicity trigger this in ./configure, instead of
having to remove GMP); she can build a GHC that is not linked
dynamically against GMP and the resulting programs are not linked
either. This makes it possible to generate binaries that link
dynamically against libc (no -static) which is quite compatible
amongst versions, but doesn't require a libgmp.so to run. For binary
deployments this seems to be the best kind of setup nowadays.
Now, if we were only able to fix this for amd64. See this:
https://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
On amd64 we can continue to compile GMP statically and link into the
binary library, we just have to compile GMP with the fPIC. I attached
the patch to fix this. Previously a similar patch has been rejected
in #4022 because "this shouldn't
be platform specific", but this is clearly not the case, this is
specific to amd64.
Tadaaaam:
```
errge@sid64:~/ghc/inplace/bin$ cat test.hs
main = print (2^100)
errge@sid64:~/ghc/inplace/bin$ ./ghc-stage2 test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
errge@sid64:~/ghc/inplace/bin$ ./test
1267650600228229401496703205376
errge@sid64:~/ghc/inplace/bin$ ldd ./test
linux-vdso.so.1 (0x00007fff79962000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b9a83000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b987a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b9676000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b92c6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe4b90a6000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe4b9d83000)
```
No GMP!
I attach the build file patch to the bugreport.
So, can we please apply this patch and just keep the in-tree GMP?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"amd64 + in-tree gmp build broken","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, the GHC build system has an in-tree GMP. This GMP seems to\r\nbe used only if there is no usable GMP found on the system and the\r\nuser didn't provide one using configure flags.\r\n\r\nWhen we build GHC using an external shared version of GMP, the\r\nresulting GHC is dynamically linked against GMP and also the\r\ngenerated programs are linked dynamically against GMP.\r\n\r\nWhen the in-tree GMP is used, it is built statically, even if the GHC\r\nwe are building is shared GHC on GNU/Linux. This feature is currently\r\nbroken on amd64 (#4366, #4022), but is working currently\r\nvery well on Linux i686.\r\n\r\nApart from the breakage this setting is very flexible and I'd be very\r\nhappy if it were possible to keep it, in spite of removeal requests\r\nlike #4374.\r\n\r\nWhen there is a system GMP, nothing would change, this is the most\r\ntypical usage, e.g. distributions are all building this way.\r\n\r\nOn the other hand, if the user removes his GMP (maybe we should\r\nprovide an option to explicity trigger this in ./configure, instead of\r\nhaving to remove GMP); she can build a GHC that is not linked\r\ndynamically against GMP and the resulting programs are not linked\r\neither. This makes it possible to generate binaries that link\r\ndynamically against libc (no -static) which is quite compatible\r\namongst versions, but doesn't require a libgmp.so to run. For binary\r\ndeployments this seems to be the best kind of setup nowadays.\r\n\r\nNow, if we were only able to fix this for amd64. See this:\r\nhttps://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3\r\n\r\nOn amd64 we can continue to compile GMP statically and link into the\r\nbinary library, we just have to compile GMP with the fPIC. I attached\r\nthe patch to fix this. Previously a similar patch has been rejected\r\nin #4022 because \"this shouldn't\r\nbe platform specific\", but this is clearly not the case, this is\r\nspecific to amd64.\r\n\r\nTadaaaam:\r\n{{{\r\nerrge@sid64:~/ghc/inplace/bin$ cat test.hs\r\nmain = print (2^100)\r\nerrge@sid64:~/ghc/inplace/bin$ ./ghc-stage2 test.hs\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\nLinking test ...\r\nerrge@sid64:~/ghc/inplace/bin$ ./test\r\n1267650600228229401496703205376\r\nerrge@sid64:~/ghc/inplace/bin$ ldd ./test\r\n linux-vdso.so.1 (0x00007fff79962000)\r\n libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b9a83000)\r\n librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b987a000)\r\n libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b9676000)\r\n libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b92c6000)\r\n libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe4b90a6000)\r\n /lib64/ld-linux-x86-64.so.2 (0x00007fe4b9d83000)\r\n}}}\r\n\r\nNo GMP!\r\n\r\nI attach the build file patch to the bugreport.\r\n\r\nSo, can we please apply this patch and just keep the in-tree GMP?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/8572Building an empty module with profiling requires profiling libraries for inte...2019-07-07T18:44:26ZparcsBuilding an empty module with profiling requires profiling libraries for integer-gmp```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module A where
```
```
$ ghc-stage2 -prof -c A.hs
Top level:
Failed to load interface for ‛GHC.Integer.Type’
Perhaps you haven't installed the profiling libraries for package ‛integ...```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module A where
```
```
$ ghc-stage2 -prof -c A.hs
Top level:
Failed to load interface for ‛GHC.Integer.Type’
Perhaps you haven't installed the profiling libraries for package ‛integer-gmp’?
Use -v to see a list of the files searched for.
```
I can't built module `A` without profiling libraries for `integer-gmp`, even though I don't use `integer-gmp` anywhere in the module.
This happens because the `Tidy Core` pass attempts to look up the `mkInteger` name (in order to desugar integer literals) even when there are no integer literals in the module.
The obvious fix is to lazily look up `mkInteger` in `Coreprep.lookupMkIntegerName`:
```diff
diff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs
index 5e0cd65..9836982 100644
--- a/compiler/coreSyn/CorePrep.lhs
+++ b/compiler/coreSyn/CorePrep.lhs
@@ -56,6 +56,7 @@ import Config
import Data.Bits
import Data.List ( mapAccumL )
import Control.Monad
+import System.IO.Unsafe ( unsafeInterleaveIO )
\end{code}
-- ---------------------------------------------------------------------------
@@ -1119,6 +1120,7 @@ lookupMkIntegerName dflags hsc_env
else if thisPackage dflags == integerPackageId
then return $ panic "Can't use Integer in integer"
else liftM tyThingId
+ $ unsafeInterleaveIO
$ initTcForLookup hsc_env (tcLookupGlobal mkIntegerName)
mkInitialCorePrepEnv :: DynFlags -> HscEnv -> IO CorePrepEnv
```
This way, we don't attempt to look up `mkInteger` until we actually need it, i.e. if there are integer literals that we must desugar.
Relevant commits are 2ef5cd26db27543ac8664a3d18f45550d0109a8b and fdd552e0ecaa17300670a48562995040e1d6687e
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Building an empty module with profiling requires profiling libraries for integer-gmp","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n#!haskell\r\n{-# LANGUAGE NoImplicitPrelude #-}\r\nmodule A where\r\n}}}\r\n\r\n{{{\r\n$ ghc-stage2 -prof -c A.hs\r\n\r\nTop level:\r\n Failed to load interface for ‛GHC.Integer.Type’\r\n Perhaps you haven't installed the profiling libraries for package ‛integer-gmp’?\r\n Use -v to see a list of the files searched for.\r\n}}}\r\n\r\nI can't built module `A` without profiling libraries for `integer-gmp`, even though I don't use `integer-gmp` anywhere in the module.\r\n\r\nThis happens because the `Tidy Core` pass attempts to look up the `mkInteger` name (in order to desugar integer literals) even when there are no integer literals in the module.\r\n\r\nThe obvious fix is to lazily look up `mkInteger` in `Coreprep.lookupMkIntegerName`:\r\n\r\n{{{\r\n#!diff\r\ndiff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs\r\nindex 5e0cd65..9836982 100644\r\n--- a/compiler/coreSyn/CorePrep.lhs\r\n+++ b/compiler/coreSyn/CorePrep.lhs\r\n@@ -56,6 +56,7 @@ import Config\r\n import Data.Bits\r\n import Data.List ( mapAccumL )\r\n import Control.Monad\r\n+import System.IO.Unsafe ( unsafeInterleaveIO )\r\n \\end{code}\r\n\r\n -- ---------------------------------------------------------------------------\r\n@@ -1119,6 +1120,7 @@ lookupMkIntegerName dflags hsc_env\r\n else if thisPackage dflags == integerPackageId\r\n then return $ panic \"Can't use Integer in integer\"\r\n else liftM tyThingId\r\n+ $ unsafeInterleaveIO\r\n $ initTcForLookup hsc_env (tcLookupGlobal mkIntegerName)\r\n\r\n mkInitialCorePrepEnv :: DynFlags -> HscEnv -> IO CorePrepEnv\r\n\r\n}}}\r\n\r\nThis way, we don't attempt to look up `mkInteger` until we actually need it, i.e. if there are integer literals that we must desugar.\r\n\r\nRelevant commits are 2ef5cd26db27543ac8664a3d18f45550d0109a8b and fdd552e0ecaa17300670a48562995040e1d6687e","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1