When running Haskell programs that import several packages like this one:
import Text.Feed.Import
import Network.HTTP
main = do
page <- simpleHTTP (getRequest "http://stackoverflow.com")
print $ page
I get an error like this one (Note: This question intends to solve the general problem, this specific case is just an example) :
GHCi runtime linker: fatal error: I found a duplicate definition for symbol get_current_timezone_seconds
whilst processing object file
/usr/lib/ghc/time-1.4.0.1/HStime-1.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
Reinstalling the packages (e.g. HTTP and feed in the above case) as described in this previous post doesn't help. How can I resolve this issue?
Why this error occurs
This issue is not specific to a single package (e.g. it was described here in relation to Yesod three years ago), but is caused by the different libraries you import (e.g. HTTP and feed) linking to different versions of a single library (this issue occurs only for libraries that export C-style symbols. Their symbol names are not unique. time is one of those packages.).
As denoted in the error message, the library that causes the issues in this specific case is time-1.4.0.1.
Diagnosing the exact problem
First, you need to identify which different versions exist of your library. You can do this by checking the packages using ghc-pkg describe <packagename>, or just take a look into your cabal installation directory (usually ~/.cabal/lib).
At the time of writing this, the issue was caused by both time-1.4.0.1 and time-1.4.1 being installed. By using ghc-pkg describe I figured out that feed (and only feed, in my case), linked to time-1.4.1 whereas about 100 libraries linked to time-1.4.0.1.
How to resolve
Identify the library version (of the library that causes the error, as denoted in the error message) as described above that fewer packages depend on. You'll need to rebuild all packages that depend on it. In my case this is time-1.4.1.
Then, uninstall the package:
$ ghc-pkg unregister time-1.4.1 --force
unregistering time-1.4.1 would break the following packages: feed-0.3.9.2 (ignoring)
Note that the feed package is now broken and needs to be rebuilt and reinstalled. After rebuilding however, it won't link to time-1.4.1 but time-1.4.0.1 (in my specific case). This re-linking will resolve the duplicate symbol problem.
$ cabal install feed
If the error still occurs after that, re-check all dependencies as described above. You need to make sure any library you import will show the same library it's linked to when analyzed with ghc-pkg describe <pkg>
Update: In order to find out, which packages depend on the problematic library, simply use ghc-pkg unregister without the --force flag (Thanks to John J. Camilleri for pointing that out!). Note that if no packages depend on said problematic package, it will be removed.
An alternative cause of the same problem, is when using common symbols in an external library, on windows. I have an issue with a fortran code base using the common symbols. It is better explained here> https://gitlab.haskell.org/ghc/ghc/-/issues/6107
This only happens in dynamic linking, so ghc works, but ghci does not.
Related
I'm trying to write a desktop program using an elm frontend with haskell backend.
To make writing the backend code idiomatically similar to the front end code (and make sending data between them easier), it would be great to use No Red Ink's custom prelude.
Stack is my build tool.
It's the first time I've tried to use a custom prelude. I can't get it to even turn up. The key unresolvable error message for me is the one with no suggested "different approaches to resolving this":
In the dependencies for nri-prelude-0.6.0.6:
unix is a library dependency, but the package provides no library`
Here's everything I tried:
I tried adding -fplugin=NriPrelude.Plugin to my ghc options in my stack.yaml but it said
<command line>: Could not find module `NriPrelude.Plugin'
So I tried adding nri-prelude to my dependencies, resulting in a recommendation to add
- nri-prelude-0.6.0.6#sha256:4ccc7488149a0401a9241c9b64db22c48a8639afaae11cffb263da5226e8acde,5289
to my stack.yaml, which resulted in a recommendation to add
- terminfo-0.4.1.5#sha256:4d1790aeb354797955ca1cb67035ca80f66a0d9cc4e43a51c1c9d566e00ce350,1713
- unix-2.7.3#sha256:20079c504d0ca33fbf11de3a215d25220c8d43499a93049a8f2791323f3bd57b,6047
as well. This was a dead end for me because I got the error message:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for nri-prelude-0.6.0.6:
unix is a library dependency, but the package provides no library
needed due to Experiment-0.1.0.0 -> nri-prelude-0.6.0.6
Some different approaches to resolving this:
Plan construction failed.
I couldn't help but notice the empty list of approaches to resolving it this time.
Instead of going down that route I tried using a route that had worked for another library, by putting
- github: NoRedInk/haskell-libraries
commit: a202da122192ad2b9435f92086f5b4c5e304531b
in my stack.yaml. It didn't like that:
No cabal file found for Archive from https://github.com/NoRedInk/haskell-libraries/archive/a202da122192ad2b9435f92086f5b4c5e304531b.tar.gz
and when I tried
- github: NoRedInk/haskell-libraries/nri-prelude
commit: 8657ef0ea153a12fcaa0d048be98598512fe9df6
that didn't even parse:
Could not parse 'stack.yaml':
Aeson exception:
Error in $['extra-deps'][3]: failed to parse field 'extra-deps': parsing Text failed, expected String, but encountered Object
See http://docs.haskellstack.org/en/stable/yaml_configuration/
I have a project with a a library in a few directories. The cabal file is produced with hpack and looks ok. The project builds with cabal build and the main can be run with cabal run xx.
Using repl in vscode, I get occasionally
Could not load module ‘GIS.Subdivisions’
It is a member of the hidden package ‘CatCoreConcepts-0.2’.
Perhaps you need to add ‘CatCoreConcepts’ to the build-depends in your .cabal file.
The package is, of courese, listed in the dependencies. The error is not always occuring and I assume it is a probem with some data cached in the vscode Haskell HLS plugin. Is there a simple way to clean the cache of the plugin? Restart HLS and Developer: reload window in vscode is not having any effect.
I have had the problem where VSCode thinks modules are hidden. Many answers on SO, such as this one. Possible solution, which hopefully helps,
ghc-pkg expose CatCoreConcepts
This is not an answer to the main question, but to some OP comments.
I'd say cabal documentation is good (but lengthy).
A brief summary as I understand (not official documentation)
A Package is a set of components
A component is a set of modules (haskell files)
Module-name and file-name must be equal except for entrypoints (see below)
Components can be classified in two groups:
runnables: tests, benchmarks and executables
runnables must have a unique main function called the entrypoint
In the cabal file, you can use keywords executable, test-suite and benchmark for defining runnables
Within each runnable section in the cabal file there must be a field main-is pointing to the file with the entrypoint
The file-name of the entrypoint can be whatever but the module name must be Main.
Notice that runnable components can have multiple modules (haskell files). For example you can have a test suit consisting in a file with auxiliar functions and other file with the main function. Both files conform a component (a test-suite in this case)
non-runnables: libraries
In the cabal file, you can use keywords library for defining non-runnable component
For libraries you must specify the modules which are exposed with the exposed-modules keyword.
Runnable components can import non-runnable ones even if they are defined in the same package. But viceversa is not true.
As a good practice, each component should be separated in a different folder. Some libraries expect naming convention. For example: tests to be in a folder with the same name and with test_XXXX.hs format (this is regular across programing languages, not only Haskell)
When libraries are separated in folders the field hs-source-dirs must be specified to point to the folder with the haskell files
(the name runnable is not part of the official docs, but is the way I understand)
stack works pretty much the same as cabal since the former is just a different front-end for the later. So aside from different keywords and yaml format, all of the above can be applied to stack (notice that cabal updates more often than stack, therefore some features supported by cabal can be missing in stack.)
If you find this useful, I think I am opening an issue to the cabal docs to include it.
I haven't tried solving the issue yet; first I want to understand where the issue comes from:
TextTerra $ stack --nix test
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for TextTerra-0.1.0.0:
easytest-0.2 from stack configuration does not match ==0.2.1 (latest matching version is 0.2.1)
needed since TextTerra is a build target.
Some different approaches to resolving this:
* Set 'allow-newer: true' to ignore all version constraints and build anyway.
* Consider trying 'stack solver', which uses the cabal-install solver to attempt to find some working build configuration. This can be convenient when dealing with many complicated constraint
errors, but results may be unpredictable.
* Recommended action: try adding the following to your extra-deps in /home/brandon/workspace/TextTerra/stack.yaml:
- easytest-0.2.1
Plan construction failed.
There is now no other reference to easytest, particularly easytest-0.2; the single reference is what I just added:
TextTerra $ rg easytest
TextTerra.cabal
67: , easytest == 0.2.1
However, there was a reference to easytest-0.2 in cabal.config. I'm not aware of the relevance of this file as a quick search doesn't turn up much and removing the file has no effect on the build (in particular, I get the same error message above).
In...
easytest-0.2 from stack configuration does not match ==0.2.1
... the "stack configuration" means the set of packages specified through the resolver (typically a Stackage snapshot -- you can find lists of packages and versions in a snapshot at the Stackage site) and the extra-deps in stack.yaml, while the ==0.2.1 constraint is what your .cabal file is asking. The suggestions given by the error message (ignoring .cabal upper bounds with allow-newer, and adding packages to extra-deps) are appropriate in the cases in which you want, or need, to build with a specific resolver. If that is not the case (say, if you are trying to update an old project to a recent LTS snapshot), you can also change the resolver to something that includes the packages and versions you are looking for (if such a resolver is available).
I'm getting the following error when trying to install the contravariant library (which is needed for lens) with Cabal:
``src/Data/Functor/Contravariant.hs:96:1:
StateVar-1.1.0.0:Data.StateVar can't be safely imported! The module itself isn't safe.''
I've not had any success googling solutions, and tried a few fixes (such as getting rid of all my Haskell packages (with ``rm -r ~/.ghc'') and starting again), but I'm not really clear on what's causing this error to occur. I'm using ghc 7.4.1 - could that be the problem?
Thanks,
Reuben
Posting the correct answer from comments as community-wiki:
Looks like you're being hit by interactions between an old GHC and the
lack of Safe Haskell annotations (in the library) that are redundant
with newer GHC versions. Cf. http://github.com/ekmett/ersatz/issues/13
I recently made a cabal package which can be seen here
It consists of a library and a few small example programs using it. Everything builds and works as expected.
I wanted to build an executable in a new package which uses this library, however I continue to run into a linking error I can't decipher:
/my/path/RandomAgent/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/rlglue-0.2.1.1/libHSrlglue-0.2.1.1.a(Agent.o):(.text+0x34f1): undefined reference to `rlgluezm0zi2zi1zi1_Pathszurlglue_version1_closure'
collect2: error: ld returned 1 exit status
To make things simpler to diagnose I moved one of the examples programs into my new package and discovered even it won't build properly. You can find that version of the executable here.
From this I've concluded that the problem is likely in something I'm doing in my .cabal files, but I can't see what's wrong. The error also seems to refer to the Paths_rlglue module which cabal automatically generates for the first package.
Can anyone help me understand why I'm getting this error?
You need to include the Paths_rlglue module in exposed-modules or other-modules like any other module in your project so that Cabal will link it.
Cabal should be better about telling you what is going on, see https://github.com/haskell/cabal/issues/1746.
Looks like I missed something in the documentation for Paths_pkgname
If you decide to import the Paths_pkgname module then it must be
listed in the other-modules field just like any other module in your
package.
Adding Paths_rlglue to my library's other-modules fixed the issue. Hope this saves someone all the time I lost on this.