# How to use GHC 7.10

**URL:** <https://discourse.haskell.org/t/how-to-use-ghc-7-10/11523>\
**Category:** Show and Tell\
**Created:** [March 1, 2025, 8:54pm UTC](https://discourse.haskell.org/t/how-to-use-ghc-7-10/11523 "2025-03-01T20:54:29Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [March 1, 2025, 8:54pm UTC](https://discourse.haskell.org/t/how-to-use-ghc-7-10/11523/1 "2025-03-01T20:54:29Z")

</div>

I managed to get a working GHC 7.10 setup, and I wanted to put all the necessary information in one place, just for future reference.

GHCup has GHC 7.10, but it notes [some warnings about linking errors that happen on modern distros](https://github.com/haskell/ghcup-metadata/blob/7b1af75f6ed9f0426be31a601d79d9870e27a443/ghcup-0.0.4.yaml#L142).

So my approach is instead to use the fpco Docker images, so that also system libraries and the C toolchain are compatible. It’s problematic, though, because the newest Docker versions use a new manifest version, and as such they can’t pull old images and more.

What I did on x86\_64 on Debian Bullseye is:

1. Install [official Docker apt repositories](https://docs.docker.com/engine/install/debian/)

2. Install a older version of Docker from mid-2024, with support for the old manifest. I picked the last v26 version:

3. Configure Docker to be able to pull old images:

4. Reboot

5. Now you should be able to run

6. In the container, you must configure [the new Stackage snapshot location](http://discourse.haskell.org/t/ann-stack-2-15-3-and-earliers-default-source-for-list-of-stackage-snapshots-not-up-to-date/9023). Stack v1.3.2 still has [documentation available online](https://docs.haskellstack.org/en/v1.3.2/yaml_configuration/). Execute `mkdir /etc/stack` and write to `/etc/stack/config.yaml`:

7. You can run `stack repl --package lens` and it will make the global project configuration file `/root/.stack/global-project/stack.yaml` with the current resolver (right now it is lts-23.10), and then fail the build.

8. Patch the global project `stack.yaml` to point at `lts-6.30`. I suppose newer ones like `lts-6.35` should also work.

9. Now commands like `stack repl --package lens` work. Using the right resolver and using the system GHC.

Note that the steps that modify the fpco image could of course be used to create new Docker image, and if that image is uploaded, it uses manifest v2, and should therefore work with current Docker versions. And hopefully a few years into the future.

To make this really future proof, I’d like to back up the source packages too at some point.

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [March 1, 2025, 9:01pm UTC](https://discourse.haskell.org/t/how-to-use-ghc-7-10/11523/2 "2025-03-01T21:01:44Z")

</div>

The GHCup message does say:

> You may have to pass ‘–ghc-option=-optc-no-pie --ghc-option=-optl-no-pie’ to cabal build/install.

That worked for me last time I encountered this. I think you can even add these as defaults in your cabal config somewhere. Why take the drastic step of using Docker?

---

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [March 1, 2025, 9:12pm UTC](https://discourse.haskell.org/t/how-to-use-ghc-7-10/11523/3 "2025-03-01T21:12:30Z")

</div>

The more modern tools I use, the more likely I am to encounter an issue. Using Docker is almost as convenient as being on the host machine. GHCup might be able to install a working compiler, but I would also be relying on modern versions of Cabal working with these ancient library versions. My goal is not to get the latest libraries working with an old compiler, my goal is to conveniently access the ecosystem as it was back then.

For even older GHC releases like 6.2.2, I am considering extracting shared objects from a RedHat Linux 9 installation and manually constructing a i386 Docker image. How’s that for drastic? 😉 How would you prefer to set up GHC 6.2.2 environment?

---

<div class="post-metadata">

**Author:** ![Swordlash](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/swordlash/32/4604_2.png) [@Swordlash](https://discourse.haskell.org/u/Swordlash)\
**Post date:** [March 1, 2025, 9:36pm UTC](https://discourse.haskell.org/t/how-to-use-ghc-7-10/11523/4 "2025-03-01T21:36:31Z")

</div>

Forgive me my curiosity but what do you need ghc 7.10 for?

---

<div class="post-metadata">

**Author:** ![AntC2](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/antc2/32/1872_2.png) [@AntC2](https://discourse.haskell.org/u/AntC2)\
**Post date:** [March 2, 2025, 10:01am UTC](https://discourse.haskell.org/t/how-to-use-ghc-7-10/11523/5 "2025-03-02T10:01:16Z")

</div>

To drill down a little on @Swordlash’s q, if you want only the compiler + Prelude, you can download and unpack from the GHC download page [\*\*].

If you’re wanting to add other packages, or even compile the compiler, I’m curioser and curioser.

[\*\*] Although I notice the url seems to be broken, should be `https://www.haskell.org/ghc/download_ghc_7_10_3.html`

---

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [March 2, 2025, 5:46pm UTC](https://discourse.haskell.org/t/how-to-use-ghc-7-10/11523/6 "2025-03-02T17:46:59Z")

</div>

If bootstrapping, I wonder if it could be useful to have a complete working environment for reference.

Let’s say a separate compiler for the GHC 8.0 sources were to be written. Maybe it would be useful to have a reference to compare with. To answer questions like “this module takes awfully long to compile, I wonder if GHC 7.10 also took ages”.

Suppose there is a bug in the type checker of GHC 7.10, which makes it able to compile a GHC 8.0 module even though it shouldn’t. The fact that for the last ~30 years, only GHC can compile itself, means that it is less likely that people would discover if GHC were too reliant on a quirk that it wasn’t supposed to be reliant on.

Does that make sense? Maybe I can retroactively come up with some other justification.