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)

(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.

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 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
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 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?

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-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.

Note: See TracTickets for help on using tickets.