Opened 4 years ago

Closed 3 years ago

#9625 closed bug (fixed)

ghc: panic using --enable-executable-dynamic

Reported by: CoreyOConnor Owned by:
Priority: normal Milestone:
Component: Package system Version: 7.8.3
Keywords: Cc: ezyang, slyfox, trommler, RyanGlScott
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by thomie)


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

Reproduction steps:

1. git clone
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.

Change History (7)

comment:1 Changed 4 years ago by thomie

Cc: ezyang added
Component: CompilerPackage system
Description: modified (diff)

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

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


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-

$ cabal build
Building foo-
Preprocessing library foo-
In-place registering foo-
Preprocessing test suite 'bar' for foo-
[1 of 1] Compiling Test             ( Test.hs, dist/build/Test.o )
In-place registering bar-
[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
Last edited 4 years ago by thomie (previous) (diff)

comment:2 Changed 4 years ago by 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

comment:3 Changed 4 years ago by rwbarton

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

rwbarton@morphism:/tmp/foo$ ghc-pkg -f dist/package.conf.inplace describe bar
name: bar
id: bar-
license: AllRightsReserved
exposed: True
exposed-modules: Test
trusted: False
import-dirs: /tmp/foo/dist/build
library-dirs: /tmp/foo/dist/build
hs-libraries: bar
depends: Cabal-
         base- foo-
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?

comment:4 Changed 4 years ago by slyfox

Cc: slyfox added

comment:5 Changed 3 years ago by trommler

Cc: trommler added

comment:6 Changed 3 years ago by RyanGlScott

Cc: RyanGlScott added

comment:7 Changed 3 years ago by thomie

Resolution: fixed
Status: newclosed

With Cabal-, the panic is gone, but the test ends with read: no parse. I have a fix for that in

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.

Note: See TracTickets for help on using tickets.