Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"ghc: panic! (the 'impossible' happened)" using "--enable-executable-dynamic" #2039

Closed
coreyoconnor opened this issue Aug 16, 2014 · 7 comments
Closed

"ghc: panic! (the 'impossible' happened)" using "--enable-executable-dynamic" #2039

coreyoconnor opened this issue Aug 16, 2014 · 7 comments
Labels
priority: high 🔥 type: bug
Milestone
2.0

Comments

@coreyoconnor
Copy link

From: jtdaugherty/vty#54

Using --enable-executable-dynamic leads to a ghc panic. Filing here as Cabal handles --enable-executable-dynamic. If this is confirmed to not be caused by Cabal (likely so IMO) then I'll move to ghc's bug tracker.

To reproduce:

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

Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu. The vty report is on Nix, which I do not have a working environment to reproduce with.
@coreyoconnor coreyoconnor mentioned this issue Aug 16, 2014
Closed
@coreyoconnor
Copy link
Author

Changing the test suite name to verifyFoo also fails. Changing the name to VerifyFoo results in a different failure:

dist/build/VerifyFoo.o: file not recognized: File truncated

@coreyoconnor
Copy link
Author

In vty, changing the test suite name has no effect: Using "VerifyAttributeOps", "AttributeOpsTest", "verifyAttributeOps", "attributeopstestsuite" All result in:

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

@23Skidoo
Copy link
Member

GHC panics are bugs in GHC. Please report this at the GHC bug tracker.

@coreyoconnor coreyoconnor mentioned this issue Sep 21, 2014
Closed
@rwbarton
Copy link
Contributor

It was reported as a GHC bug in https://ghc.haskell.org/trac/ghc/ticket/9625

However, to the best of my understanding, it may still be a bug in Cabal. (That is, even if GHC did not panic, GHC would instead exit with an error.) In thomie's simplified example, cabal is building a dynamic Haskell library with the name libbar-ghc7.8.3.so, and registering a package with hs-libraries: bar. Normally these libraries have names like libHSbar-ghc7.8.3.so and this is what is causing the panic. Does anyone understand whether the HS prefix is really necessary?

@srijs srijs mentioned this issue Feb 21, 2015
Closed
@peti peti mentioned this issue May 13, 2015
Open
@robertmassaioli
Copy link

Does anybody have a workaround for this? It's affecting my nix installations:

In-place registering test-descriptor-0.4.0.2...
[1 of 1] Compiling Main             ( dist/build/test-descriptorStub/test-descriptorStub-tmp/test-descriptorStub.hs, dist/build/test-descriptorStub/test-descriptorStub-tmp/Main.dyn_o )
Linking dist/build/test-descriptorStub/test-descriptorStub ...
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.1 for x86_64-apple-darwin):
    Don't understand library name test-descriptor

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

builder for ‘/nix/store/yq7zv4ad6a71sa9jk14l1xm89in7b53f-haskell-atlassian-connect-descriptor-0.4.0.2.drv’ failed with exit code 1
cannot build derivation ‘/nix/store/gxbr64m2dzrxxckmm9ar8l80rsz9vdk6-ghc-7.10.1.drv’: 1 dependencies couldn't be built
error: build of ‘/nix/store/gxbr64m2dzrxxckmm9ar8l80rsz9vdk6-ghc-7.10.1.drv’ failed
/Users/rmassaioli/.nix-profile/bin/nix-shell: failed to build all dependencies

This is for the atlassian-connect-descriptor package: http://hackage.haskell.org/package/atlassian-connect-descriptor

@ttuegel ttuegel added this to the Cabal-1.24 milestone Jun 30, 2015
@ttuegel
Copy link
Member

ttuegel commented Jun 30, 2015

I think this is a bug in the detailed test suite builder. I'm not sure why the HS prefix is missing; the test suite library is built with the same mechanism as ordinary libraries, so it too should have the prefix.

@ttuegel ttuegel reopened this Jun 30, 2015
@peti peti mentioned this issue Oct 14, 2015
Closed
@23Skidoo 23Skidoo modified the milestones: Cabal 1.24, Cabal 1.26 Feb 21, 2016
@peti peti mentioned this issue May 17, 2016
Closed
thomie added a commit to thomie/cabal that referenced this issue Jul 8, 2016
@thomie
Add test build directory to LD_LIBRARY_PATH when running tests with -…
7f1dedf 
…executable-dynamic

Since commit 18fcd9c, Cabal builds the stub
executable and the test library for a LibV09 (detailed-0.9) test in
different directories.

This is good, but when running the test with --enable-executable-dynamic, we
now have to add the test build directory to (DY)LD_LIBRARY_PATH, so that the
linker can find the test library when running the stub executable (see haskell#2289
for details).

This fixes haskell#2039. The GHC panic mentioned in that ticket must have been
resolved earlier already.
thomie added a commit to thomie/cabal that referenced this issue Jul 8, 2016
@thomie
Add test build directory to LD_LIBRARY_PATH when -executable-dynamic
a2b7da6 
Since commit 18fcd9c, Cabal builds the stub
executable and the test library for a LibV09 (detailed-0.9) test in
different directories.

This is good, but when running the test with --enable-executable-dynamic, we
now have to add the test build directory to (DY)LD_LIBRARY_PATH, so that the
linker can find the test library when running the stub executable (see haskell#2289
for details).

This fixes haskell#2039 (read: no parse). The GHC panic mentioned in that
ticket must have been resolved earlier already, perhaps also by commit
18fcd9c.
thomie added a commit to thomie/cabal that referenced this issue Jul 8, 2016
@thomie
Add test build directory to LD_LIBRARY_PATH when -executable-dynamic
f6d24ab 
Since commit 18fcd9c, Cabal builds the stub
executable and the test library for a LibV09 (detailed-0.9) test in
different directories.

This is good, but when running the test with --enable-executable-dynamic, we
now have to add the test build directory to (DY)LD_LIBRARY_PATH, so that the
linker can find the test library when running the stub executable (see haskell#2289
for details).

This fixes haskell#2039 (read: no parse). The GHC panic mentioned in that
ticket must have been resolved earlier already, perhaps also by commit
18fcd9c.
@thomie thomie mentioned this issue Jul 8, 2016
Closed
@ezyang
Copy link
Contributor

ezyang commented Aug 16, 2016

No longer occurs with GHC 7.10 and later, closing fixed.

@ezyang ezyang closed this as completed Aug 16, 2016
@ezyang ezyang modified the milestones: Cabal 2.0, 2.0 (planned for next feature release) Sep 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
priority: high 🔥 type: bug
Projects
None yet
Milestone
2.0
Development

Successfully merging a pull request may close this issue.

Add test build directory to LD_LIBRARY_PATH when -executable-dynamic thomie/cabal
6 participants
@ezyang @rwbarton @coreyoconnor @23Skidoo @robertmassaioli @ttuegel