I'm trying to install hdbc-sqlite with Cabal in Windows. I found some help from this nice post, but the installation of Sqlite3's dll and def files failed on a package called lifted-base-0.1.1 because of an unrecognized option --disable-benchmarks.
Maybe I could fix this problem by modifying the installer's source code and removing this unrecognized option, and then manually installing the package, if manual installations are possible? Or is there a less tedious solution?
Did you try cabal update?
I would first try a more recent version (of lifted-base) like 0.1.2 or 0.2. Then I would manually download the tar file and use this (change the path in the import command).
Also try to upgrade your GHC / Haskell platform, you apparently describe a known issue.
Related
When I run the config file for installing GSL library for Windows 10 I get the following error:
error: Something went wrong bootstrapping makefile fragments for
automatic dependency tracking. If GNU make was not used, consider
re-running the configure script with MAKE="gmake" (or whatever is
necessary). You can also try re-running configure with the
'--disable-dependency-tracking' option to at least be able to build
the package (albeit without support for automatic dependency
tracking).
If I run ./config MAKE="gmake" I still get the error. I have searched in StackOverflow and on the web and still haven't found a solution.
I've just installed Haskell Platform 8.6.5 in Windows 10 (latest download from https://www.haskell.org/platform/), and when trying "cabal new-update" or "cabal v1-update", it answers with the following error message.
Downloading the latest package list from hackage.haskell.org
cabal.exe: Could not read index. Did you call 'checkForUpdates'?
I have found no other question regarding this issue here, and although there is one on GitHub (https://github.com/haskell/cabal/issues/5574), no solutions so far, at least for Windows.
Can I use cabal on Windows at all?
I have searched and read all cabal related problems I could, both on here and on GitHub, but most are either for Linux or OS. No good answers for Windows...
I have tried the "cabal -v3 v2-update" and it showed me the file that was missing and its path. At first I tried to restore the file by hand, but someone suggested erasing all the files related to the missing one, and, voilá, cabal regenerate all of them and started to work.
The file missing was called 001-index.cache, and I erased all the files 001-index*.
The path was C:\Users\fidel\AppData\Roaming\cabal\packages\hackage.haskell.org.
Thanks everybody for the suggestions and help.
I am trying to install pysam.
After excecuting:
python path/to/pysam-master/setup.py build
This error is produced:
unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1
There are similar threads, but they all seem to address the problem assumig administriator rights, which I do not have. Is there a way around to install the needed files?
DISCLAIMER: This question derived from a previous post of mine.
manually installing pysam error: "ImportError: No module named version"
But since it might require a different approach, I made it a question of its own.
You can also receive the same error while installing some R packages if R was installed using conda (as I had).
Then just install the package by executing: conda install gxx_linux-64 to have that command available.
Source:
https://github.com/RcppCore/Rcpp/issues/770#issuecomment-346716808
It looks like Anaconda had a new release (4.3.27) that sets the C compiler path to a non-existing executable (quite an embarrassing bug; I'm sure they'll fix it soon). I had a similar issue with pip installing using the latest Miniconda, which I fixed by using the 4.3.21 version and ensuring I was not doing something like conda update conda.
See https://repo.continuum.io/miniconda/ which has release dates and versions.
It should now be safe to update conda. This is fixed in the following python packages for linux-64:
python-3.6.2-h0b30769_14.tar.bz2
python-2.7.14-h931c8b0_15.tar.bz2
python-2.7.13-hac47a24_15.tar.bz2
python-3.5.4-hc053d89_14.tar.bz2
The issue was as Jon Riehl described - we (Anaconda, formerly Continuum) build all of our packages with a new GCC package that we created using crosstool-ng. This package does not have gcc, it has a prefixed gcc - the missing command you're seeing, x86_64-conda_cos6-linux-gnu-gcc. This gets baked into python, and any extension built with that python goes looking for that compiler. We have fixed the issue using the _PYTHON_SYSCONFIGDATA_NAME variable that was added to python 3.6. We have backported that to python 2.7 and 3.5. You'll now only ever see python using default compilers (gcc), and you must set the _PYTHON_SYSCONFIGDATA_NAME to the appropriate filename to have the new compilers used. Setting this variable is something that we'll put into the activate scripts for the compiler package, so you'll never need to worry about it. It may take us a day or two to get new compiler packages out, though, so post issues on the conda-build issue tracker if you'd like to use the new compilers and need help getting started.
Relevant code changes are at:
py27: https://github.com/anacondarecipes/python-feedstock/tree/master-2.7.14
py35: https://github.com/anacondarecipes/python-feedstock/tree/master-3.5
py36: https://github.com/anacondarecipes/python-feedstock
The solution that worked for me was to use the conda to install the r packages:
conda install -c r r-tidyverse
or r-gggplot2, r-readr
Also ensure that the installation is not failing because of admin privileges.
It will save you a great deal of pain
After upgrading Golang to 1.19.1, I started to get:
# runtime/cgo
cgo: C compiler "x86_64-conda-linux-gnu-cc" not found: exec: "x86_64-conda-linux-gnu-cc": executable file not found in $PATH
Installing gcc_linux-64 from the same channel, has resolved it:
conda install -c anaconda gcc_linux-64
Somewhere in your $PATH (e.g., ~/bin), do
ln -sf $(which gcc) x86_64-conda_cos6-linux-gnu-gcc
Don't put this in a system directory or conda's bin directory, and remember to remove the link when the problem is resolved upstream. gcc --version should be version 6.
EDIT: I understand the sentiment in the comments against manipulating system paths, but maybe we can use a little critical thinking for the actual case in hand before reciting doctrine. What actually have we done with the command above? Nothing more than putting an executable (symlink) called x86_64-conda_cos6-linux-gnu-gcc in one's personal ~/bin directory.
If putting something in one's personal ~/bin directory broke future conda (after it fixes the C compiler path to point to gcc it embeds), then that would be a bug with conda. Would the existence of this verbosely named compiler mess with anything else? Unlikely either. Even if something did pick it up, it's just your system gcc after all...
I'm going to install GHC on a fresh copy of Ubuntu and I'm wondering: How can I ensure that profiling libraries are installed for the core libraries (e.g., text, unordered-containers)?
I'm aware of the changing the profiling option in cabal's .config file but my understanding is that this only ensures that profiling libraries are installed for those packages that I install AFTER setting up cabal (see italicized text in update below).
(I inadvertently blew up my Ubuntu vbox last night as a result of trying to retroactively install profiling libraries for installed GHC packages. It led to the existing packages not working, which led to me trying to uninstall GHC, which led to...KABOOM!)
UPDATE:
I've installed GHC and am now at the point where I'm about to install cabal. I've confirmed my suspicion that I'm facing a "chicken-and-an-egg" dilemma: In order to get the initial cabal config file (in which I can set profiling option as True), I need to install cabal. However, installing cabal results in the installation of core packages (e.g., text, unordered-containers) BEFORE I get a chance to make the change in the cabal config file.
SOLVED:
As per Daniel Wagner's suggestion (thanks!), I made a couple of modifications to the bootstrap.sh script file (I unfortunately didn't have my old cabal or I would've followed his other suggestion). As reference for future readers, the beginning of my bootstrap.sh file looked like this (after the changes):
#VERBOSE
DEFAULT_CONFIGURE_OPTS="--enable-library-profiling --enable-shared"
EXTRA_CONFIGURE_OPTS=${EXTRA_CONFIGURE_OPTS-$DEFAULT_CONFIGURE_OPTS}
#EXTRA_CONFIGURE_OPTS
#EXTRA_BUILD_OPTS
#EXTRA_INSTALL_OPTS
The preferred solution is to install cabal-install via your package manager. If you have an old version of cabal-install in your package manager, you can then use the old version to install the new version with a config in place, or even specify profiling directly on the command line via cabal install cabal-install --enable-library-profiling.
An alternate solution if you plan to install cabal-install via its bootstrap.sh script is to use the environment variables it provides for configuration. There are four, notated at the top of bootstrap.sh; the relevant one is EXTRA_CONFIGURE_OPTS, which contents get passed to the configure step of each package's Setup command. So something like this ought to do the trick (though I haven't tested it):
EXTRA_CONFIGURE_OPTS=--enable-library-profiling ./bootstrap.sh
So I recently installed cabal (from the default binary of ArchLinux).
I then tried to upgrade cabal as a user:
cabal upgrade Cabal --user --prefix=$USER
Resolving dependencies...
cabal: fromFlag NoFlag. Use fromFlagOrDefault
What I've already done:
Googled the error message. Turned up the cabal source and little else.
Looked at haskell-wiki on cabal-install.
Looked through this guide.
So basically I'm wondering:
What's up with the error message?
Could anyone point me in the direction of a cabal tutorial?
I think that's a bug in Arch's package. I'm running Arch as well, and I got the same error.
I then built cabal-install (0.8.2) from Hackage, which didn't complain when I run cabal upgrade Cabal. In fact, it started building right away, although I didn't let it finish because I didn't feel comfortable upgrading a core package.
May I ask why you wanted to upgrade Cabal? The version that comes with ghc is 1.8.0.2, and the latest version is 1.8.0.4 -- not too distant IMO. Besides, if you're running cabal-install as normal user, why not simply cabal install? It doesn't have permission to overwrite the system files anyway.
I'm guessing wildly here, but can you see if
You have a nonstandard Setup.hs?
You have flags: set in ~/.cabal/config?
The most helpful tutorial I have found is not ostensibly about Cabal; it is called How to Write a Haskell Program.
I have looked through the guide you mention (the official Cabal documentation), and the information I wanted is a tiny bit of flotsam swimming in a sea of complexity. I assume that the complexity serves some useful purpose, since I know that good people have been working very hard on Cabal for several years, but as an outsider, I find the state of play discouraging. I was just barely able to build, install, and upload a simple package of my own—with a little help from my friends on SO.
I tentatively suggest you might want to avoid cabal upgrade and maybe try cabal install instead, and see if you can move forward with your original goals.
From user tlo:
The global configuration file for cabal-install is ~/.cabal/config. If
you do not have this file, cabal will create it for you on the first
call to cabal update.
I deleted my config, ran cabal update, and all was good.