ghc: panic using --enable-executable-dynamic

[CoreyOConnor]

(from: ​https://github.com/haskell/cabal/issues/2039)

Using --enable-executable-dynamic leads to a ghc panic.

Reproduction steps:

1. git clone https://github.com/coreyoconnor/executable-dynamic-issue
2. cabal configure --enable-tests --enable-executable-dynamic
3. cabal test

Expected results: Test executes and passes.

Actual results:

ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Don't understand library name verify-foo

Actual results varies based on the name of "verify-foo" test suite. Other names tried: "verifyFoo", "VerifyFoo". All of which also fail.

Removing "--enable-executable-dynamic" results in a pass regardless of test suite name.

Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu.

[thomie]

I ran into other problems trying to reproduce this with ghc HEAD, but can confirm the bug exists in 7.8.3 (and 7.8.3.20141105). Here's a slightly simplified testcase:

$ cat foo.cabal 
name:          foo
version:       0.1.0.0
build-type:    Simple
cabal-version: >=1.8

Library

Test-Suite bar
  type:          detailed-0.9
  test-module:   Test
  build-depends: foo, base, Cabal

$ cat Setup.hs 
import Distribution.Simple
main = defaultMain

$ cat Test.hs 
module Test where
import Distribution.TestSuite
tests :: IO [Test]
tests = return []

$ cabal configure --enable-tests --enable-executable-dynamic
Resolving dependencies...
Configuring foo-0.1.0.0...

$ cabal build
Building foo-0.1.0.0...
Preprocessing library foo-0.1.0.0...
In-place registering foo-0.1.0.0...
Preprocessing test suite 'bar' for foo-0.1.0.0...
[1 of 1] Compiling Test             ( Test.hs, dist/build/Test.o )
In-place registering bar-0.1.0.0...
[1 of 1] Compiling Main             ( dist/build/barStub/barStub-tmp/barStub.hs, dist/build/barStub/barStub-tmp/Main.dyn_o )
Linking dist/build/barStub/barStub ...
ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.3 for x86_64-unknown-linux):
	Don't understand library name bar

[Luke]

I'm seeing this on 7.8.4 as well when compiling vty package.

ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.4 for x86_64-unknown-linux):
        Don't understand library name verify-attribute-ops

[rwbarton]

So Cabal is building and registering (inplace) a package bar with the field hs-libraries: bar and a corresponding shared library libbar-ghc7.8.3.so:

rwbarton@morphism:/tmp/foo$ ghc-pkg -f dist/package.conf.inplace describe bar
name: bar
version: 0.1.0.0
id: bar-0.1.0.0-inplace
license: AllRightsReserved
copyright:
maintainer:
stability:
homepage:
package-url:
synopsis:
description:
category:
author:
exposed: True
exposed-modules: Test
hidden-modules:
trusted: False
import-dirs: /tmp/foo/dist/build
library-dirs: /tmp/foo/dist/build
hs-libraries: bar
extra-libraries:
extra-ghci-libraries:
include-dirs:
includes:
depends: Cabal-1.18.1.3-4452332f737ff7dce6018eada45af877
         base-4.7.0.1-1a55ebc8256b39ccbff004d48b3eb834 foo-0.1.0.0-inplace
hugs-options:
cc-options:
ld-options:
framework-dirs:
frameworks:
haddock-interfaces: /tmp/foo/dist/doc/html/bar/bar.haddock
haddock-html: /tmp/foo/dist/doc/html/bar
pkgroot: "/tmp/foo/dist"

However, Haskell libraries usually have hs-libraries with names like HSbar.

In b30015e78db99d79cdb48c6c810e3fd49573c5cd GHC started to enforce this, since it applies different rules for finding the shared library base name for hs-libraries depending on whether they start with HS or with C. As far as I can tell this is only used by rts, specifically in its dependency on libffi. I have to say I don't understand why libffi can't simply be an extra-libraries dependency, something to do with library search paths perhaps?

Is there any other reason for the convention that Haskell library names start with HS? Is this convention documented anywhere?

[thomie]

With Cabal-1.24.0.0, the panic is gone, but the test ends with read: no parse. I have a fix for that in ​https://github.com/haskell/cabal/pull/3527.

Closing this ticket here, as it is a Cabal issue now.

Is there any other reason for the convention that Haskell library names start with HS? Is this convention documented anywhere?

I have no idea.