non-standard cabal-dev directory, GHCi runtime linker: fatal error #98

Closed
jfeltz opened this Issue Jan 17, 2013 · 26 comments

Projects

None yet

4 participants

@jfeltz
jfeltz commented Jan 17, 2013

I don't know enough about Haskell yet to really determine if the problem is with ghc-mod or just my setup. I just want to use ghc-mod in conjunction with cabal-dev. Just an FYI, the package builds normally with cabal-dev --sandbox=./sandbox64 build, and the following error seems to occur no matter which source file in the package that I run 'check' on.

ghc-mod version 1.11.3, ghc 7.4.2, haskell-platform 2012.4.0.0, cabal-dev 0.9.1 built with Cabal 1.14.0
jpf@dev1:~/portfolio$ ghc-mod --sandbox=./sandbox64 check src/Main.hs

GHCi runtime linker: fatal error: I found a duplicate definition for symbol
__hscore_S_IFDIR
whilst processing object file
/home/jpf/local/ghc-7.4.2/lib/ghc-7.4.2/directory-1.1.0.2/HSdirectory-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.
@achudnov
achudnov commented Feb 7, 2013

Hi,
I have a similar issue, but my cabal-dev directory is standard. I'm using cabal-dev with ghc-mod. The package builds without failure even without sandboxing (i.e. 'cabal-dev build' succeeds). Note that I also have a 64-bit system.
Note that the following error is only present ghc-mod >= 1.11.2. Rolling back to ghc-mod-1.11.1 solves it.

GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   my_inet_ntoa
whilst processing object file
  <projectdir>/cabal-dev//lib/network-2.4.0.1/ghc-7.4.1/HSnetwork-2.4.0.1.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.

EDIT: I have tested the same setup (ghc-mod-1.11.3 with ghc-7.4.1 and cabal-dev) but on a 32-bit machine and it works fine. My guess is that ghc-mod-1.11.2 has introduced an incompatibility with cabal-dev on 64-bit systems.

@kazu-yamamoto
Collaborator

I have completely rewritten the logic to find a sandbox. The latest released ghc-mod includes this logic. If you still have problems, please let me know.

@jfeltz
jfeltz commented Mar 13, 2013

Solved as of cabal-dev 0.9.2, ghc 7.4.2, ghc-mod 1.12.1, thanks.

@jfeltz jfeltz closed this Mar 13, 2013
@achudnov

I still have this problem, now even on the 32-bit machine (it used to fail only on a 64-bit). Using cabal-dev-0.9.2, ghc-mod-1.12.2, ghc-7.4.1. Please reopen or advise on the solution. The error message I'm getting is the same as in my post above. I'll be happy to provide additional info.
EDIT: Looks like the latest version that works for me is ghc-mod-1.11.1.

@jfeltz jfeltz reopened this Mar 13, 2013
@kazu-yamamoto
Collaborator

Please do two things:

  1. ghc-pkg check

This command lets you know if installed libraries are broken.

  1. ghc-mod debug <target.hs>

This command lets you know which cabal file/sandbox are used.

If you find something, please let me know.

@achudnov

Kazu, thank you for a prompt reply

Short version: I haven't found anything suspicious in the outputs of 'ghc-pkg check' or 'ghc-mod debug'.

Long version:

  1. 'ghc-pkg check' only returned two warnings for missing haddock files; probably not what you are looking for.
Warning: haddock-interfaces: /usr/lib/ghc-doc/haddock/curl-1.3.7/curl.haddock doesn't exist or isn't a file
Warning: haddock-html: /usr/share/doc/libghc-curl-doc/html/ doesn't exist or isn't a directory
  1. 'ghc-mod debug Main.hs' in the project directory (projectdir) returned the following information, which, as far as I can tell, is correct (e.g. the .cabal file name, the path to packages-conf and the dependent packages are all correct):
GHC version:         7.4.1
Current directory:   <projectdir>
Cabal file:          <projectdir>/<project>.cabal
GHC options:         -package-conf <projectdir>/cabal-dev/packages-7.4.1.conf -no-user-package-conf -XScopedTypeVariables -XHaskell2010
Include directories: <projectdir>
Dependent packages:  HTTP, QuickCheck, arrows, base, bytestring, cmdargs, containers, data-default, fgl, hs-proxy, http-encodings, hxt, jespresso, language-ecmascript, mime, mtl, network, parsec, pretty, random, regex-tdfa, template-haskell, test-framework, test-framework-quickcheck2, text, transformers, uniplate
Fast check:          Yes

Here's the output of 'ls cabal-dev/packages-7.4.1.conf':

ansi-terminal-0.6-5fe5cc159c9aa74e59a82d5acdd0457f.conf
ansi-wl-pprint-0.6.6-f8b52fab36a60394d1ba9d571a11c2a7.conf
arrows-0.4.4.1-a2778652248d240e3b4415e7783605ba.conf
charset-0.3.4-8022c7d5e0e95bf7ca727cfb03a69a17.conf
cmdargs-0.9.7-059318d9924e0d83d68f7010589ad91a.conf
data-default-0.5.1-3a7c700b7e484a4042095b57f9356d16.conf
dlist-0.5-7276363a34fcf2df7f951f5361c66146.conf
hashable-1.2.0.5-fc9fbb2b50da41dc7dacd2a2c990376d.conf
hostname-1.0-f8064aa7c2dc842ecc0af88b780d2d8f.conf
hs-proxy-0.1.3-07491c7917805d82026f3b730ea4efbb.conf
HTTP-4000.2.8-321e5a6ee3b5a1def543dffc9b8de04c.conf
http-encodings-0.3-2a42fc71ce3798a800c557a8f82a2868.conf
http-server-1.0.3-b46105c8660c5ecc2ed714908b79de48.conf
hxt-9.3.1.1-ffa9e3c3313fad28216fac4409e47227.conf
hxt-charproperties-9.1.1-4bb740c52fee26bdca2ea9364d9d55c4.conf
hxt-regex-xmlschema-9.1.0-8fcd789588a9d2179f5c477e3adde61d.conf
hxt-unicode-9.0.2-c18ee103aa70e57153c7e7c18e00d986.conf
iconv-0.4.1.1-be4933f7f27a95cc63200f9f90fbe66f.conf
jespresso-0.2.0.0-7b83bb8ee835c6e1eaa5be674a0a468b.conf
jsinline-0.1-40e03c69f0b7462e064f59945a345a61.conf
language-ecmascript-0.11.1-5d25bbeeb3a249f062a4a02749ed1d7e.conf
lazysmallcheck-0.6-49a7e994e609104db41293c390f97480.conf
mime-0.3.4-d4fafd5805a427f7323c14dd9161c25a.conf
nats-0.1-e6c8ea0cc1a194687c2d6e3f52c0ffe4.conf
network-2.4.1.2-7f334d8cdd52d02afff5535854d1baf2.conf
package.cache
QuickCheck-2.5.1.1-cd0c6d7a0341dc0a256aac5736d4343e.conf
regex-tdfa-1.1.8-d1d6e0401c6280b73399938888e70d02.conf
semigroups-0.9-a5ce0021fa231fdc4d2d3dfafdc4b653.conf
Stream-0.4.6.1-b8e01c06e604bcf11c01c972f18d5a56.conf
test-framework-0.8-79799330e877979c0da51fdedd0b50ed.conf
test-framework-quickcheck2-0.3.0.1-2007f50645ac31aa31221aa0ab824d41.conf
uniplate-1.6.10-f7a12a043f421b66717cc13952ec0d63.conf
unordered-containers-0.2.3.0-19473bf116e09e5d9a61e9c9a8673b83.conf
url-2.1.3-8786ef01b73ec28bfc8839c10c3476a0.conf
utf8-string-0.3.7-ca3bc669f78a10f8e42ef22439bcf83c.conf
xml-1.3.12-5561ea21bd297a3af3ed25602dd911e7.conf

For your reference, here's the error message given by 'ghc-mod check Main.hs' issued in :

GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   my_inet_ntoa
whilst processing object file
  <projectdir>/cabal-dev//lib/network-2.4.1.2/ghc-7.4.1/HSnetwork-2.4.1.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.

I can verify that the file /cabal-dev//lib/network-2.4.1.2/ghc-7.4.1/HSnetwork-2.4.1.2.o exists.

@kazu-yamamoto
Collaborator

Can cabal build compile your code?

Where is my_inet_ntoa defined?

@kazu-yamamoto
Collaborator

Suppose that you have a library foo version X installed globally by HP. If you install the library foo of the same version X in user level (~/.cabal or sandbox), a problem occurs. In this situation, even cabal build does not work.

@achudnov

Can cabal build compile your code?

I don't use 'cabal' in my development projects -- I use 'cabal-dev'. And, yes, 'cabal-dev' can compile my code without any issues.

Where is my_inet_ntoa defined?

It's defined in 'network'. Looks like an FFI binding.

./include/HsNet.h:116:my_inet_ntoa(
./Network/Socket.hsc:1577:foreign import ccall unsafe "my_inet_ntoa"

Suppose that you have a library foo version X installed globally by HP. If you install the library foo of the same version X in user level (~/.cabal or sandbox), a problem occurs. In this situation, even cabal build does not work.

Well, I checked the network library and it's version in the global package config (2.3.0.10) is not the same as in the sandbox (2.4.1.2). And as I said, the package builds just fine.

On another note, I have a few other, much smaller, projects, some of which directly depend on network. I have just checked them with the latest version of ghc-mod, and it worked on all of them. It's strange, I know.

@kazu-yamamoto
Collaborator

What does ghc-pkg check --package-conf <projectdir>/cabal-dev/packages-7.4.1.conf --no-user-package-conf say?

@achudnov

Only haddock warnings:

Warning: haddock-interfaces: <projectdir>/cabal-dev//share/doc/jespresso-0.2.0.0/html/jespresso.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: <projectdir>/cabal-dev//share/doc/hs-proxy-0.1.3/html/hs-proxy.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /usr/lib/ghc-doc/haddock/curl-1.3.7/curl.haddock doesn't exist or isn't a file
Warning: haddock-html: /usr/share/doc/libghc-curl-doc/html/ doesn't exist or isn't a directory
@kazu-yamamoto
Collaborator

OK.

Can I see your .cabal file?

@kazu-yamamoto
Collaborator

I do believe your "/.ghc" is broken. I don't know you can do this. But if I were you, I would remove "/.ghc" and "~/.cabal", then install necessary things with cabal or cabal-dev.

@achudnov

Removed .ghc and .cabal, reinstalled my global packages:

cabal update
cabal install cabal-install
cabal install cabal-dev
cabal install ghc-mod
cabal install stylish-haskell hoogle

Reinstalled the cabal-dev sandbox for the project as well. Nothing has changed: the error persists.

I'm emailing my .cabal file to you.

@kazu-yamamoto
Collaborator

What does cabal-dev list -s <projectdir>/cabal-dev/packages-7.4.1.conf say about the network package?

@achudnov

Kazu, I'm sorry I forgot to reply to your question. The bad news is that I'm still having the same problem with one project using the latest version of ghc-mod (1.12.4) -- the one I've sent you the .cabal file from. The good (at least for you :)) news is that it started working with other (smaller) projects that also rely on network. Here's what cabal-dev list -s <projectdir>/cabal-dev/packages-7.4.1.conf had to say about the network package

* network
    Synopsis: Low-level networking interface
    Default available version: 2.4.1.2
    Installed versions: 2.3.0.13
    Homepage: https://github.com/haskell/network
    License:  BSD3

I'm really not sure how to interpret the "Installed versions" field, though: the version in the local sandbox as installed by cabal-dev is 2.4.1.2. The same goes for all the other packages that use network and which work fine with ghc-mod (in fact, the output of cabal-dev list -s <projectdir>/cabal-dev/packages-7.4.1.conf seems to be similar for all the packages).

@kazu-yamamoto
Collaborator

I have no idea on this issue.

The following patch shows libraries specified to GHC API. If you apply the patch, what does ghc-mod check <file.hs> say? Is "network" duplicated?

diff --git a/GHCApi.hs b/GHCApi.hs
index e6f4f13..53e13c2 100644
--- a/GHCApi.hs
+++ b/GHCApi.hs
@@ -74,6 +74,7 @@ initSession :: Build
             -> Bool
             -> Ghc LogReader
 initSession build opt cmdOpts idirs mDepPkgs logging = do
+    liftIO $ print mDepPkgs
     dflags0 <- getSessionDynFlags
     (dflags1,readLog) <- setupDynamicFlags dflags0
     _ <- setSessionDynFlags dflags1
@achudnov

No, '''network''' is not duplicated. Here's the full output given by the patched command.

Just ["HTTP","QuickCheck","arrows","base","bytestring","cmdargs","containers","data-default","fgl","hs-proxy","http-encodings","hxt","jespresso","language-ecmascript","mime","mtl","network","parsec","pretty","random","regex-tdfa","template-haskell","test-framework","test-framework-quickcheck2","transformers","uniplate"]
@kazu-yamamoto
Collaborator

OK. This is not a source of the problem.

BTW. Your problem is very similar to: http://stackoverflow.com/questions/13186428/how-to-work-around-duplicate-symbol-error-when-using-yesod-and-darcs-library

Any thoughts?

@achudnov

The error message in the stack overflow question is the same as mine, modulo the symbol name and the object file. I ran the handy shell script that the original author used to list the libraries that have a certain symbol. Here's what I've got:

$ for file in `find cabal-dev/lib/ -name "*.a"`; do (readelf -s $file | grep -i my_inet_ntoa) && (echo $file; echo); done
  1724: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND my_inet_ntoa
     8: 0000000000000000    14 FUNC    GLOBAL DEFAULT    1 my_inet_ntoa
cabal-dev/lib/network-2.4.1.2/ghc-7.4.1/libHSnetwork-2.4.1.2.a

However, I've got the exact same output for two other projects that use cabal-dev and depend on network, but work fine with ghc-mod. Also, I did some further experiments: ghc-mod only seems to give the error for certain .hs files, but not others in the same project. Preliminary investigation shows that those files that cause an error are the only ones that import from packages that depend on network. I'll continue my experiments and update when/if I have some new data.

The code diff between 1.11.1 and 1.11.2 is not that large, I think I'll try to analyze that.

@kazu-yamamoto
Collaborator

Just FYI: the diff b/w 1.11.1 and 1.11.2 is large from the technical point of view. ghc-mod 1.11.1 does not specify dependency libraries in a cabal file but ghc-mod 1.11.2 does.

@achudnov

Kazu,
The bug is no longer present for me after upgrading to ghc-7.6.3 and ghc-mod-2.0.3. I still have no idea what was the reason, but, I guess, you can close this issue now. Thanks for the support.

@kazu-yamamoto
Collaborator

Oh, really? Your bug was introduced when ghc-mod started to use Cabal to parse a cabal file. I found that we misused the library and we must use finalizePackageDescription. After correcting usage of the library, your bug disappeared. Congratulation and thank you for your report and patience! Let's close this ticket.

@achudnov

Thanks again. Good to know I wasn't completely crazy with this bug. Just a word of caution: the bug was still present for me on ghc-7.4.2 even with the latest ghc-mod. But with the release of the new haskell-platform containing ghc-7.6.3, I guess, it's irrelevant now.

@kazu-yamamoto
Collaborator

Thank you for your explanation. I know the GHC API of v 7.4.2 have a lot of bugs.

@alanz
alanz commented Jun 3, 2013

On the network versions issue, I have had similar problems in the past which I tracked down to system versions vs user versions.

For example, on my box running GHC 7.4.2 I have

$ ghc-pkg list
/usr/local/lib/ghc-7.4.2/package.conf.d
..
   mtl-2.1.2
   network-2.3.1.0
..
/home/alanz/.ghc/i386-linux-7.4.2/package.conf.d
..

For GHC 7.6.3 I have

~$ ghc-pkg list
/usr/local/lib/ghc-7.6.3/package.conf.d
..
   network-2.4.1.2
..

If you install a user version of a package that is in the system list for the given GHC installation, it will give you weir linkage and version problems.

I presume this carries over into any of the virtualised environments too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment