bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41508: GHC retains references to Perl, GCC, and others


From: Ricardo Wurmus
Subject: bug#41508: GHC retains references to Perl, GCC, and others
Date: Tue, 26 May 2020 09:07:24 +0200
User-agent: mu4e 1.4.4; emacs 26.3

Ricardo Wurmus <address@hidden> writes:

> GHC installs a lib/settings file with references to build-time tools,
> such as Perl, GCC, and others.
>
> I tried building with a phase that removed those references:
>
>      (match (find-files (string-append (assoc-ref outputs "out") "/lib")
>                         "settings")
>        ((settings)
>         (remove-store-references settings))
>        (_ #f))
>
> Unfortunately, this breaks all Haskell packages as GHC always first
> tries to set up its build environment.  Any Haskell package’s configure
> phase fails as GHC fails to find GCC.
>
> It seems to me that the only way around this is to patch GHC to allow
> looking up of GCC and Perl through environment variables, but perhaps
> this is unrealistic.

When I looked at that settings file again, I noticed that the LLVM tools
are named without an absolute file name.  So I patched it to refer to
its tools by the basename (“gcc” instead of “/gnu/store/…/bin/gcc”, etc)
and that did the trick.

--8<---------------cut here---------------start------------->8---
   (substitute* (find-files (string-append (assoc-ref outputs "out") "/lib/")
                            "settings")
     (("/gnu/store/.*/bin/(.*)" m program) program))
--8<---------------cut here---------------end--------------->8---

This means, however, that people who install GHC to compile things will
need to also install gcc-toolchain (and perhaps perl), as GHC will try
to invoke them.  Not propagating these tools means that users of Haskell
packages providing an executable (such as Pandoc) will benefit from a
smaller package closure.

Perhaps it would be better not to mess with the “settings” file and
instead work on cutting references from Haskell packages to GHC itself.
The main reason why Haskell packages retain references to GHC is due to
the set of Haskell packages that GHC provides.  If we could separate GHC
from the set of core packages it provides then Haskell packages could
reference the packages they depend on without also dragging in GHC
itself.

-- 
Ricardo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]