Following an upgrade to OS X El Capitan, Cabal and GHC are no longer found on my system:
-bash: ghc: command not found
-bash: cabal: command not found
What do I need to do to get Cabal and GHC working on OS X El Capitan?
I've found the following approach most reliable on all versions of OSX including El Capitan.
Install Homebrew
Run brew install ghc
Run brew install cabal-install
This approach allows you to easily install the latest versions and have multiple versions installed and easily switch between them using the brew switch command. Haskell Platform lacks these properties, which is why the advanced users tend to avoid it any way.
Edit: There is now a released version that fixes these issues.
This is all caused by the new "rootless security" features in El Capitan.
You don't need to copy or reinstall the programs -- the files in /usr/bin were always just symlinks, to things available in /Library/Frameworks/GHC.framework/ and /Library/Frameworks/HaskellPlatform.framework. So you should be able to symlink them again (to /usr/local/bin this time) from there.
See also https://github.com/haskell/haskell-platform/issues/205
Hopefully a new platform release that fixes these issues will be out soon.
I believe El Capitan does not allow users to change /usr anymore which is where the Haskell binaries are installed.
If you can copy/install the programs into /usr/local/bin they should work from there.
If the programs are not visible anymore in /usr/bin, I would suggest reinstalling the HP into a different partition. Then copy them to /usr/local.
Let me know how it goes.
Related
Background: My CentOS have no access to the Internet and upgrading OS isn't permitted, but I can upload files to it. I want to use YCM to complete my c++ code.
I intended to install YCM on centos6.3 which have a clang2.8, but YCM needs libcalng3.9. So I have to upgrade my clang and llvm. Then I follow this tutorail to install llvm with source code, however I found that gcc cmake and many other fundamental tools also must be upgraded, or many errors would occur.
In order to install new tool chain, I have downloaded CentOS7.iso and use it as a local yum repo to upgrade development toolset. I don't know whether this way is proper, and it falt into loop dependence. So my questions are below.
Can install YCM without upgrade my development toolset?
Is there an easy/hard way to upgrade my development toolset?
What is the reason that I can't install software on CentOS6.3 using CentOS7.4?
You may use scientific linux's devtoolset packages from http://mirror.centos.org/centos/6/sclo/x86_64/rh/devtoolset-7/
Use rpm or yum to install devtoolset-7 and its dependecies. New binaries will be installed into /opt/rh/devtoolset-7/root/usr/bin. To make use of them you must add the path to the PATH environment variable.
The packages contain prebuilt binaries which require specific versions of shared librarirs, which are not available on mismatched version of centos.
I am new to Linux (new as in installed it yesterday), I need it for my programming course in the university and I've been told to install specific versions of specific programs, but though I've used apt-get install to install them (having previously done apt-get update) they aren't in the correct version.
The programs that I need are make 4.0 and valgrind 3.10.1.
apt-get installs make 3.81 and valgrind 3.10.0.SVN.
I have tried typing "apt-get install make4.0" and "apt-get install valgrind10.3.1" to no avail. I have downloaded them from the internet and followed what instructions I could understand to install the newer versions but it keeps saying that I have the older ones. (I'm not sure if I can post direct links here, if I can let me know and I'll post where I got them from).
What have I been doing wrong? How can I fix this?
I am currently running Linux Mint.
Thanks for any answer in advance.
Due to a long-standing unresolved Debian bug report, GNU Make remained the age-old 3.81 in Debian for a very long time, and as a consequence, in Debian-based distributions such as Ubuntu and Mint.
The latest Debian release, Jessie, has upgraded to 4.0, so Debian-based distributions will have that upgrade. However, it is better to use 4.1.
This has been discussed many times on the GNU Make mailing list and elsewhere.
So to get a newer version, you must compile it from scratch.
This is easy:
Install the required packages (gcc, make and such).
Open up a shell (if you're using the GUI, a terminal window).
Type the following commands (or something equivalent, e.g. you can use curl instead of wget):
cd /tmp
wget http://ftp.gnu.org/gnu/make/make-4.1.tar.gz
tar xvf make-4.1.tar.gz
cd make-4.1/
./configure
make
sudo make install
cd ..
rm -rf make-4.1.tar.gz make-4.1
Now, make 4.1 is in /usr/local/bin/make.
You can verify it is there with whereis make.
You can make it your default make by prefixing /usr/local/bin to your $PATH variable in your shell startup file; for instance, in .profile or .bashrc if you use the bash shell.
Don't try to install a self-compiled make (or anything else that doesn't come from the distribution's package manager) into /bin or /usr/bin; doing that will confuse your package manager.
I am currently trying to update Cabal (1.14.0, cabal-install at version 0.14.0) by doing
cabal install cabal-install
However, this gives me an ExitFailure1 with the error
setup: The program ghc version >=6.4 is required but the
version of /usr/bin/ghc could not be determined.
But I'm definitely running a version of GHC that is greater than that.
$ /usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.2
It might be important that I'm on OSX 10.8 and that I installed Haskell through the Haskell Platform download for Mac.
Does anyone have advice on how to fix or work around this issue? I haven't been able to find any documentation on this problem.
Since you're on a Mac, why not try installing the excellent Homebrew package manager? Add /usr/local/bin to your PATH, and then it's just brew install cabal-install.
You can even brew install ghc haskell-platform.
To upgrade the package list, use brew upgrade, then you can see what needs updating with brew outdated and update them with brew update.
Of course, you can name individual packages to update also, and specify versions of packages. Homebrew keeps the "recipes" (Ruby scripts) for package management in its own git repository (by default in /usr/local).
Then you can get on with what you really wanted to do in the first place...write some code! (or build, in your case)
So, this is a bit of a personal problem, but maybe people will have good advice or workarounds.
The problem is about installing cabal-install and haskell-platform under Debian.
When you apt-get install haskell-platform, it ships with cabal-install, and its command cabal is available.
Now this cabal-install is not up-to-date:
> which cabal
/usr/bin/cabal
> /usr/bin/cabal --version
cabal-install version 0.8.0
using version 1.8.0.2 of the Cabal library
But, my understanding of running cabal update is that it updates cabal, but since it is not a "Debian thingy", it puts it in ~/.cabal/bin/.
> ~/.cabal/bin/cabal --version
cabal-install version 0.8.2
using version 1.8.0.2 of the Cabal library
Now my system has 2 cabals, and the one I get by typing cabal is not the one I want to use... Because it'll keep updating the other one instead of itself, and is therefore ineffective.
So what I did was I aliased it in my ~/.bashrc:
alias cabal='~/.cabal/bin/cabal'
Now:
> cabal --version
cabal-install version 0.8.2
using version 1.8.0.2 of the Cabal library
So, my final questions:
Is there a deb repository that holds cabal 0.8.2?
Could my current solution lead to problems? (For instance, which cabal still points to my useless /usr/bin/cabal, so if scripts use this command they'll get fooled...)
Did someone come up with a better solution? (Mine is a bit ad-hoc but that's all I could come up to with my poor knowledge of what is happening behind the scenes...)
Please correct me if anything I say above is wrong or inaccurate.
What I do is installing cabal with the --global flag. This will install cabal into /usr/local/bin/cabal, thus it will always superseed the Debian packages cabal.
Another way, is to generally avoid the Debian packages and install the Haskell platform straight from its source. This approach is also better, if you always want to have the latest releases of the Haskell libs.
I keep my user-local $HOME/.cabal/bin in the front of the PATH.
I install only ghc6, ghc6-prof, ghc6-doc and cabal-install from the distribution packages. I don't use distribution cabal-install for anything more than to bootstrap the new ~/.cabal.
All the rest I install with cabal install, including the newer cabal itself.
When I want to use newer GHC, I deploy it in /usr/local/stow/ghcVERSION, and enable it with GNU stow (it adds symlinks in /usr/local which, again, has precedence in my PATH). When I want to switch back to the distribution GHC I just run stow -D to remove all symbolic links to it.
I consider using cabal-dev to have project-specific cabal installations, and avoid broken dependencies which happen with cabal from time to time.
As a matter of fact I don't use Haskell Platform at all because I don't need all of it and find it easier to be able to install individual libraries. I do not install distribution libraries, because not all of them are available or are exactly the versions I need; and it is much easier to control conflicts if all of them are installed in the same place (~/.cabal in my case). I do not install anything with --global, because I think it is wrong and difficult to rollback.
Of course this information gets out of date, but yes, Debian unstable and testing have, at the time of writing, cabal-install 0.10.2.
Generally, the Debian packaging of Haskell stuff is aimed at users who want a set of packages that is known to work together, i.e. no dependency hell, at the expense of not always having the latest and greatest. This includes cabal-install. I use cabal-install from the repositories, and only to install those libraries that have not been packaged for Debian yet.
Disclaimer: I am one of the guys that create those packages for Debian.
On Ubuntu I also tend to install GHC via stow, ignoring the system packages altogether.
One slight twist from jetxee's approach is that I do install the Haskell Platform (from source), lumping it in with the GHC stow directory. I suppose I ought to call the paths /usr/local/stow/haskell-platform-VERSION, but I tend to use /usr/local/stow/ghc-VERSION instead.
I originally installed haskell 6.10.4 using macports, but due to some bugs in it, I tried uninstalling it and installing the newer version 6.12.3 directly from the haskell site.
The installer worked fine, but when I start up ghci, it defaults to the macports version 6.10.4 that apparently wasn't uninstalled.
I attempted to use:
sudo ports uninstall haskell
to get rid of the macports version, apparently unsucessfully. How do I get macports to totally wipe the version that it put on my drive?
If you have installed items that depend on haskell then you need to uninstall those first or you can try using the --follow-dependents flag:
sudo port uninstall --follow-dependents haskell
Alternatively you can use the --force switch which will nuke only haskell no matter what, but then you may have other items broken which depend on it.
YEa another thing you could do is just make sure the path to the version of haskell you manually installed is before the path to macports on your $PATH.