GHC fails when GHC_PACKAGE_PATH contains trailing slash

When the directory given in GHC_PACKAGE_PATH contains a trailing slash, GHC stops working completely.

For example, this works:

env GHC_PACKAGE_PATH=/raid/src/ghc/ghc-atomic-writes/_build/stage1/lib/package.conf.d /raid/src/ghc/ghc-atomic-writes/_build/stage1/bin/ghc "--make" "-outputdir" "example-programs-build/" "example-programs/Hello.hs" "-o" "example-programs-build/haskell-hello"

but adding a trailing / like GHC_PACKAGE_PATH=/path/to/package.conf.d/ fails:

env GHC_PACKAGE_PATH=/raid/src/ghc/ghc-atomic-writes/_build/stage1/lib/package.conf.d/ /raid/src/ghc/ghc-atomic-writes/_build/stage1/bin/ghc "--make" "-outputdir" "example-programs-build/" "example-programs/Hello.hs" "-o" "example-programs-build/haskell-hello"    

[1 of 1] Compiling Main             ( example-programs/Hello.hs, example-programs-build/Main.o ) [Prelude changed]

example-programs/Hello.hs:1:1: error:
    Could not find module ‘Prelude’
    There are files missing in the ‘base-4.12.0.0’ package,
    try running 'ghc-pkg check'.
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
  |
1 | main :: IO ()
  | ^

This is surprising; most programs accept trailing slashes where directories are expected, and shells ofthen TAB-complete directories this way. It wastes developer time when they don't notice.

Trac metadata

Trac field	Value
Version	8.6.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	nh2
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

added newcomer label

changed weight to 3

Trac metadata

Trac field	Value
Priority	normal → low

This bug is subtler than it first appears. In particular, it's easily reproduced with the relocatable-by-default Hadrian build of the stage 2 compiler, but isn't with a non-relocatable Makefile build.

The issue is in compiler/main/Packages.hs function readPackageConfig where pkgroot is set to takeDirectory conf_file. If conf_file has a trailing slash, this just drops the slash instead of the final directory component. Then in mungePackageConfig processing, this will cause bad substitutions for ${pkgroot} when processing (cached) package configuration data. This causes problems with the Hadrian build, where we have lines in base-4.13.0.0.conf like:

library-dirs:
    ${pkgroot}/../lib/x86_64-linux-ghc-8.9.0.20190501/base-4.13.0.0

but doesn't have much effect on make-based builds where the configuration files have absolute paths here.

This is fairly easily fixed. I favor doing the "is this a file" and "is this a directory" checking in readPackageConfig using the original path (i.e., with the trailing slash if any), so a path intended to be a directory won't match a file. However, once the path has been resolved, we should strip the trailing separator for any further processing (path munging, the path string that's returned from readPackageConfig, etc.).

Creating a test case will be a little tough, but I'll try to adapt one of the package cache tests in tests/driver.

Also, there's some similar code in the ghc-pkg source that looks like it may have been fixed (at least one dropTrailingPathSeparator for a key takeDirectory call), and the other uses of takeDirectory don't appear to have the same problem. However, that code is really messy and hard to follow, so I'm not sure. We may end up in a situation where GHC handles the trailing slash okay but it causes problems with ghc-pkg.

assigned to @kabuhr

mentioned in merge request !874 (closed)

mentioned in commit 37be0713

mentioned in merge request !909 (closed)

mentioned in commit 3eb7c285

mentioned in commit 0d099a42

mentioned in commit 92bd7f1a

mentioned in commit a7b98985

closed via commit 9d238791

mentioned in commit 9d238791

added Plow label