#9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: | Owner: CoreyOConnor | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Package | Keywords: system | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Compile- | time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ezyang (added) * component: Compiler => Package system Old description:

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

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

Reproduction steps:

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

New description: (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. -- Comment: 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: {{{ #!haskell $ 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 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9625#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (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? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9625#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9625#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: 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.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9625#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler