Opened 2 years ago

Last modified 4 months ago

#7779 new bug

building GHC overwrites the installed package database if GHC_PACKAGE_PATH is set

Reported by: heatsink Owned by:
Priority: normal Milestone: 7.12.1
Component: Build System Version: 7.4.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

When building GHC, if GHC_PACKAGE_PATH is set to a single path, then the build process will register packages in that path instead of in the build tree. Since GHC_PACKAGE_PATH points to the host compiler's package database, the build system overwrites the host compiler's package database, rendering the host compiler unusable.

To reproduce:

  1. Get a binary distribution of GHC 7.4.1 and a source distribution of GHC 7.4.2
  1. Configure the binary distribution to install in a temporary directory: ./configure --prefix=$HOME/workspace1
  1. Install the binary distribution
  1. Set up the environment to use only the installed compiler: export PATH=$HOME/workspace1/bin:$PATH; export GHC_PACKAGE_PATH=$HOME/workspace1/lib/ghc-7.4.1/package.conf.d
  1. Configure the source distribution to install in a different directory: ./configure --prefix=$HOME/workspace2
  1. Build the source distribution: make

Building will eventually run commands that modify the package database in GHC_PACKAGE_PATH. One of these commands is "inplace/bin/ghc-pkg" update --force rts/package.conf.inplace. I confirmed that the database is being modified by making ghc-pkg print the name of the file it's about to update.

Change History (6)

comment:1 Changed 2 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 7.8.1
  • Owner set to igloo

Thanks for the report.

comment:2 Changed 22 months ago by igloo

Hmm, having thought about it, isn't that exactly what you'd expect to happen?

I wonder if we should just deprecate/remove GHC_PACKAGE_PATH. You already can't use cabal if it's set (cabal will just fail).

comment:3 Changed 22 months ago by heatsink

I expect building software to pose no risk of breaking any installed software. It is understandable that installing software may break other software, but building should not.

I've been using GHC_PACKAGE_PATH to install two versions of GHC that both call themselves ghc-7.4.2. By default, they both look in the same user package database, which breaks at least one of the two versions because packages are not compatible with both GHCs. Setting GHC_PACKAGE_PATH fixes that problem. Cabal works if given options --global --package-db=$FOO. If this way of managing paths is deprecated, then I'd like to have an alternative.

comment:4 Changed 21 months ago by igloo

  • Owner igloo deleted

Ah, I suspect you have an old version of cabal; it looks like 1.14 doesn't mind GHC_PACKAGE_PATH being set. But in 1.16 it just fails:

$ cabal --version
cabal-install version 1.16.0.2
using version 1.16.0 of the Cabal library 

$ export GHC_PACKAGE_PATH=something

$ cabal install text
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with
Cabal. Use the flag --package-db to specify a package database (it can be used
multiple times).

$ echo $?
1

You can use flags such as -package-db and -global-package-db with GHC too.

comment:5 Changed 12 months ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.10.1

Moving to 7.10.1

comment:6 Changed 4 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

Note: See TracTickets for help on using tickets.