v1-install fails with internal libraries

[andreasabel]

Lifted from:

• Build failure (hackage-cli) with weird linker error (due to builder using v1-install) hackage-server#1173

cabal v1-install chokes on the hackage-cli executable in the linking phase. @gbaz suspects it is because hackage-cli defines an internal library (cabal-revisions):

$ cabal get hackage-cli-0.1.0.0
$ cd hackage-cli-0.1.0.0
$ cabal v1-install -w ghc-9.4.4
...
Building library 'cabal-revisions' for hackage-cli-0.1.0.0..
...
Building executable 'hackage-cli' for hackage-cli-0.1.0.0..
...
[5 of 5] Linking dist/build/hackage-cli/hackage-cli
Installing internal library cabal-revisions in /Users/abel/.cabal/lib/x86_64-osx-ghc-9.4.4/hackage-cli-0.1.0.0-Dk3ZdfpjcyF4Z0aP4NlJOe
Installing executable hackage-cli in /Users/abel/.cabal/bin
Failed to install hackage-cli-0.1.0.0
Error: cabal: Some packages failed to install:
hackage-cli-0.1.0.0-Dk3ZdfpjcyF4Z0aP4NlJOe failed during the final install
step. The exception was:
dieVerbatim: user error (Error: cabal: '/usr/local/bin/ghc-pkg-9.4.4' exited
with an error:
z-hackage-cli-z-cabal-revisions-0.1.0.0: Warning: haddock-interfaces:
/Users/abel/.cabal/share/doc/x86_64-osx-ghc-9.4.4/hackage-cli-0.1.0.0/html/hackage-cli.haddock
doesn't exist or isn't a file
z-hackage-cli-z-cabal-revisions-0.1.0.0: Warning: haddock-html:
/Users/abel/.cabal/share/doc/x86_64-osx-ghc-9.4.4/hackage-cli-0.1.0.0/html
doesn't exist or isn't a directory
z-hackage-cli-z-cabal-revisions-0.1.0.0: installed package info from too old
version of Cabal (key field does not match id field)
)

The last line of the error "installed package info from too old version of (key field does not match id field)" is also present in this issue:

• cabal test fails to include dependency from library in test suite #4668

[andreasabel]

This issue is maybe more relevant as cabal v1-install happy fails now (since happy-2.0).

• Regression in 2.0: cabal v1-install happy fails with mysterious interface error happy#315

The error message is quite hermetic:

$ cabal v1-install happy
...
Completed    happy-lib-2.0.2
...
Building executable 'happy' for happy-2.0.2...
[1 of 2] Compiling Paths_happy      ( dist/build/happy/autogen/Paths_happy.hs, dist/build/happy/happy-tmp/Paths_happy.o )
[2 of 2] Compiling Main             ( app/Main.lhs, dist/build/happy/happy-tmp/Main.o )
/Users/abel/.cabal/lib/x86_64-osx-ghc-9.10.1-2e29/happy-lib-2.0.2-15p6rBDzTdm9pd5BXGUD6u/Happy/Backend/LALR.hi
Declaration for lalrBackendDataDir
Unfolding of lalrBackendDataDir:
  getDataDir1 ErrorWithoutFlag
                Something is amiss; requested module  happy-lib-2.0.2-15p6rBDzTdm9pd5BXGUD6u-backend-lalr:Paths_happy_lib differs from name found in the interface file happy-lib-2.0.2-15p6rBDzTdm9pd5BXGUD6u-backend-glr:Paths_happy_lib (if these names look the same, try again with -dppr-debug)
<no location info>: error:
    Cannot continue after interface file error

The least that should happen for this issue is a proper error like "v1-install not supported for package with internal libraries".

[sgraf812]

This issue presumably came up again in haskell/happy#328, which wants to use Setup.hs for packaging happy in Arch. It appears that this issue is a blocker for anyone wanting to package binaries of haskell libraries with private sub-libraries.

[Vekhir]

During packaging of happy-lib, it seems that Cabals Setup copy command doesn't copy correctly when specifying --libsubdir in the Setup configure step and writes the Paths_happy_lib file to the wrong location. This happens for both, so the second one overwrites the first.

To reproduce the issue, setting --libsubdir to any value produces the invalid artifact. Not specifying it doesn't exhibit this issue. After running the copy command with --verbose (and including other debug info like the directory structure), I got the below attached log.

Log

with --libsubdir=\$compiler/site-local/\$pkgid

without --libsubdir