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.

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

GHCi runtime linker: duplicate definition for symbol _getProcessExitCode #34

Open
pjonsson opened this issue May 17, 2014 · 5 comments
Open

Comments

@pjonsson
Copy link

Sorry for all the bug reports but here's what I get on a clean checkout of latest BulidWrapper:

$ buildwrapper synchronize --cabalfile=buildwrapper.cabal
<Lots of things synchronized>
$ buildwrapper configure --cabalfile=buildwrapper.cabal
<Some warnings
...
package ghc-7.6.3 requires Cabal-1.16.0
package bin-package-db-0.0.0.0 requires Cabal-1.16.0
package buildwrapper-0.8.2 requires Cabal-1.20.0.0
...
but result is [true, ..]>
$ buildwrapper build --cabalfile=buildwrapper.cabal
...
ghc: could not execute: htfpp
<fails>

Ok, so build everything did not work for some reason. Let's try a single file:

$ buildwrapper build1 --file=src/Language/Haskell/BuildWrapper/Cabal.hs --cabalfile=buildwrapper.cabal
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   _getProcessExitCode
whilst processing object file
   /usr/local/Cellar/ghc/7.6.3/lib/ghc-7.6.3/process-1.1.0.2/HSprocess-1.1.0.2.o
This could be caused by:
   * Loading two different object files which export the same symbol
   * Specifying the same object file twice on the GHCi command line
   * An incorrect package.conf entry, causing some object to be
     loaded twice.
GHCi cannot safely continue in this situation.  Exiting now.  Sorry.

Same thing happens with --file=.../Src.hs, --file=.../Packages.hs and so on.

After this happened I removed my installed version of buildwrapper and dynamic-cabal and installed the latest dynamic-cabal from hackage. After that I ran cabal clean in the tree of buildwrapper and installed a new version. After that I ran cabal clean and rm -rf .dist-buildwrapper before reproducing the problem again.

Am I using buildwrapper in ways that it wasn't designed to be used, or is it my system that is acting up? I have a standard installation of GHC 7.6.3 through Homebrew and after that I've run cabal install for getting my Haskell dependencies.

@JPMoresmau
Copy link
Owner

I don't think you're using buildWrapper in a different way than supposed, no, but I think you must be the only one using BuildWrapper directly and not as support forEclipseFP. Anyway, do you have several versions of process installed? Or, run the full test suite that comes with BuildWrapper. This of course I launch after every change, so it would tell you if everything is ok with buildwrapper. All tests in the test suite should pass.
In general BuildWrapper works with itself, because I use EclipseFP to develop buildwrapper...

@pjonsson
Copy link
Author

I had two versions of process installed. Not sure how I got the second, but I removed that and the htfpp message went away. I ran the test suite for 10 minutes, but couldn't see any activity after that so I aborted. My resulting buildwrapper-0.8.2-buildwrapper-test.log is 633 lines and ends with:

+++ OK (3790ms)

[TEST] Language.Haskell.BuildWrapper.CMDTests:OutlinePatternGuards (test/Languag
e/Haskell/BuildWrapper/CMDTests.hs:915)
out:configuring because setup_config not present

build-wrapper-json:[[["BWTest.cabal","Setup.hs","src/A.hs","src/B/C.hs","src/B/D
.hs","src/Main.hs","test/Main.hs","test/TestA.hs"],[]],[]]

err:
out:
build-wrapper-json:[]

err:
out:
build-wrapper-json:[{"m":"A","p":["-D__GLASGOW_HASKELL__=706"],"a":["-package-name","BWTest-0.1","-w","-v0","-fbuilding-cabal-package","-outputdir","/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build","-odir","/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build","-hidir","/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build","-stubdir","/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build","-i","-i/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build","-isrc","-i/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build/autogen","-I/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build/autogen","-I/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build","-optP-include","-optP/private/var/folders/qd/h1ktxfr97b1892hpnt7h8x6m0000gn/T/BWTest/.dist-buildwrapper/dist/build/autogen/cabal_macros.h","-hide-all-packages","-package-id","base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57","-XHaskell98"],"c":""},[]]

err:
out:
build-wrapper-json:<very long message>
[a] -\u003e Bool"},{"n":"GHC.List.or","t":["Function"],"s":"[Bool] -\u003e Bool"},{"n":"GHC.List.repeat","t":["Function"],"s":"fTest suite buildwrapper-test: FAIL
Test suite logged to: dist/test/buildwrapper-0.8.2-buildwrapper-test.log

Is the test suite expected to take 10+ minutes?

@JPMoresmau
Copy link
Owner

Yes, probably, the test suite takes a little while because to test, we have to go through the buildwrapper executable, we can't test the API directly (because of the way the GHC API works: you can only set some static flags once).

@pjonsson
Copy link
Author

I started a sandbox for buildwrapper and ran individual parts of the test suite. ImportsTests work and run quickly. CabalDevTests fail pretty quickly on both tests and the reason is that I don't have cabal-dev installed. I ran CMDTests for 3 hours and after that I aborted. There is no active process and no visible CPU-usage, and no error message. This is all I see on my screen until I abort:

Running 1 test suites...
Test suite buildwrapper-test: RUNNING...

Running cabal -v3 test gives a lot of output, but that output is relating to the compilation happening before the actual test runs, not the tests themselves. The output file is apparently only written after I abort, so there's no obvious way to snoop on the test process.

A random idea is thathtfpp was the weak link earlier, but it compiles now. I don't know if it runs though--does BuildWrapper assume that you have . in your PATH?

@JPMoresmau
Copy link
Owner

All the tests use htfpp, so if some tests run quickly, it's not the culprit. 3 hours seem excessive, yes (-:.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants