Currently I am using cabal-install 1.16.0
I tried to update cabal-install because someone told me that newer version of ghc (7.6.1) is available. Installation result was quite successful except for this message.
Warning: could not create a symlink in /Users/MyName/Library/Haskell/bin
for cabal because the file exists there already but is not managed by cabal.
You can create a symlink for this executable manually if you wish. The
executable file has been installed at
/Users/MyName/Library/Haskell/ghc-7.4.1/lib/cabal-install-1.16.0.2/bin/cabal
I checked those locations and there was files. So installation was ok.
Based on the warning message I got, I tried to create symlinks in /Users/MyName/Library/Haskell/bin by typing this.
ln -s /Users/MyName/Library/Haskell/bin /Users/MyName/Library/Haskell/ghc-7.4.1/lib/cabal-install-1.16.0.2/bin/cabal
but It gives me simple, but frustrating message. "File Exists"
So I tried again, with existing file removed by Finder. (I just move symlink file to recycle bin.) but machine gives me same message. "File Exists"
As a result, I still have installed folder, but not working Cabal, which keep urges me to update. (version 1.16.0)
How can I solve this problem?
I realize this question was asked 6 months ago, I hope you've already found the solution. I'm posting the answer here for future reference.
You were almost there. Removing the existing symlink is the correct first step. The next step is to create the new symlink by doing:
ln -s [actual/path/to/cabal] [name_of_symlink]
You seem to have reversed this order, and this causes the "File Exists" error.
Related
Problem with installation of gtkada on x86_64-linux. I am installing it into a directory $HOME/Ada and everything is ok up to the ./configure stage where I get "error: old version found". I did not want to disturb any old versions in case they were used by the system, so I'm not sure how to get round this error.
Steps in the process :-
(1) Downloaded the .tar file into $HOME/Ada.
(2) Downloaded file gnat-2021-20210519-x86_64-linux-bin into $HOME/Ada and executed it, installing in the suggested directory $HOME/opt/GNAT/2021.
(3) Extracted the files from the .tar file.
(4) Included directories $HOME/Ada and $HOME/opt/GNAT/2021 in $PATH.
(5) Ran ./configure: "error: old version found"
Note : Environment variable $PKG_CONFIG_PATH is empty (surprisingly).
Help on this will be gratefully appreciated.
Ubuntu 20.04, downloaded singularity 3.7.3.tar.gz, sha256 matches, unzipped it and followed instructions but keep getting
Failed to get package version. Abort.
Any quick suggestions what I'm missing. I installed GO using a snap, and when I check the version I get
$ go version go version go1.16.3 linux/amd64
What am I missing. Thx, J.
I found a bug / problem!
In the file
/singularity/mconfig
is some code to check the version?
# if test -z "${package_version}" ; then
# echo "Failed to get package version. Abort."
# exit 1
# fi
I can't tell why this doesn't work because the file it is looking for is present.
If I comment out this code, the config, compile and install work seamlessly and do produce the correct version information! The syslabs.io people make it incredibly difficult to contact them to suggest a bug.
V2, got it to work, this is new to me but the quirk was I was downloading the .tar.gz into a directory that was already within a git repo. This affects where mconfig looks for the "VERSION" file and causes an error. Created a new directory outside any git repo's, dowloaded, untarred and mconfig,make, and make install all worked fine. Strange thae where it looks for VERSION file is changed?
I have successfully run composer for Laravel projects in the past, but this time it doesn't want to work. None of the existing threads on StackOverflow had any useful solutions for me.
I re-installed composer, and it lives at Users/becky. I tried moving it to /usr/bin/, since that seems to be where CL thinks it lives, but then I get this message: "No such file or directory"
Okay! I'm stumped! Any takers?
TYPO:
mv /Users/becky/composer.phar /usr/loca/bin/composer.phar
SHOULD BE:
mv /Users/becky/composer.phar /usr/local/bin/composer.phar
Based on the name of your user directory, I'm guessing you're on OS X. OS X, since El Capitan, does not allow access to /usr/bin. Instead, install composer in /usr/local/bin. That directory is in your path by default and you have access to it.
To move it from your directory, use:
mv /Users/becky/composer.phar /usr/local/bin/composer.phar
Then create an alias:
alias composer="/usr/bin/php /usr/local/bin/composer.phar"
I'm trying get Homebrew working with Xcode Command Line Tools, and they seem to be having it out with each other... In the words of Rodney King, "Can't we all just get along?"
For some background, when I first got my Mac about a year ago, I had no idea what I was doing. I was also using macports, which was, as the Homebrew website seems to be cognizant, driving me to become a raging alcoholic. As a result, my /usr/local directory got wayyy f-ed up. Eventually, gcc and g++ stopped working, and a lot of other things were breaking. So I did a clean install of OS X, and I want my shiny new installation to stay a little more organized.
Now, I've installed Apple's Command Line Tools, and all the binaries/libraries/etc have ended up in /usr/local. That's fine, but then I try to install homebrew, and it's also putting everything in the /usr/local/ directory. When I run the command
brew doctor
I get the following output (actually, this is just a snippet, but it captures the general spirit of what Homebrew is telling me):
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libatomic.a
/usr/local/lib/libgfortran.a
/usr/local/lib/libgmp.a
/usr/local/lib/libgomp.a
/usr/local/lib/libitm.a
/usr/local/lib/libmpc.a
/usr/local/lib/libmpfr.a
/usr/local/lib/libquadmath.a
/usr/local/lib/libssp.a
/usr/local/lib/libssp_nonshared.a
/usr/local/lib/libstdc++.a
/usr/local/lib/libsupc++.a
I thought I might place Homebrew in a different directory; however, the Homebrew documentation specifically warned against this. They say:
"Do yourself a favor and install to /usr/local. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing to /usr/local. Pick another prefix at your peril!"
The whole point is that I don't want to bother with micro-managing every package I install, and I don't want my filesystem to become an ungodly mess either. Anyone have any suggestions? Do I move command line tools to a different directory and add this to my $PATH? Any tips would be much appreciated.
It's a warning, and the message says why. If you later want to install a Homebrew formula that installs one of those files, it will fail, because it will decline to overwrite those files, and then you will have to delete those files, as the message says.
Specifically, those files appear to belong to an installation of gcc. You might want to research or try to remember why that was installed there. It's probably OK to just delete them and install gcc from Homebrew if you need it.
I'm trying to get the Mercurial Eclipse plugin to use my MacPorts version of Mercurial (since I need to access a repo that's using the new dotencode format), but I can't get the Mercurial preference page under "Team" to save the changes. It will recognize "/opt/local/bin" as a valid directory for the "hg" executable, but when exiting the workspace the changes don't appear to be saved properly, since the next time I launch Eclipse, the old "/usr/local/bin" is back there again.
Has anyone else had problems with this? "/opt/local/bin/hg" is a symlink to "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/hg" on my system, but that file also contains a shebang ("#!") with the same path (duh!). Is that known to cause any problems on anyone else's machine?
Edit: Symlinking /usr/local/bin/hg to /opt/local/bin/hg works, but this doesn't fix the cause of the problem.
There are no errors being logged in the Eclipse Error Log view, other than "abort: requirement 'dotencode' not supported!" on startup. I.e. no errors on validating the settings or when saving the workspace.
Do you have another version of hg in /usr/local/bin? If not or if you no longer need it, you might be able to work around the issue by making a symlink:
sudo ln -s /opt/local/bin/hg /usr/local/bin/hg
sudo chmod -h g+rx,o+rx /usr/local/bin/hg