I have just installed GHC 8.10.7 via GHCup on my Windows 10. I have an earlier release already installed (ghc 9.2.1). After installing ghc 8.10.7 I got the following info:
In order to run ghc and cabal, you need to adjust your PATH variable.
To do so, you may want to run 'source /c/ghcup/env' in your current terminal
session as well as your shell configuration (e.g. ~/.bashrc).
How to understand this information, since when I run source /c/ghcup/env in the terminal I get this:
PS C:\Users\ephra> source /c/ghcup/env
source: The term 'source' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
PS C:\Users\ephra>
And it seems that ghc 8.10.7 is not visible:
PS C:\Users\ephra> ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.1
PS C:\Users\ephra>
GHC 8.10.7 folder:
C:\ghcup\ghc\8.10.7
To do so, you may want to run 'source /c/ghcup/env' in your current terminal
session as well as your shell configuration (e.g. ~/.bashrc).
This works in a Linux terminal, but going by your prompt you're using PowerShell on Windows. To use the ghc command, you'll need to update your Path environment variable. This answer already covers how to modify your Path so I'm not going to write that again here - just follow the steps there to add C:\ghcup\bin to your path and you should be fine.
NOTE: Look at this comment below the linked answer to save yourself some time.
Related
I have built llvm-13.0.1 from source using Visual Studio 17 2022 on Windows 11. When attempting to build llvm-sys (through external crate llvm-ir). It fails, saying:
error: No suitable version of LLVM was found system-wide or pointed to by LLVM_SYS_130_PREFIX.
I know llvm-config exists because I can use it from the command line, and it returns the correct version. I don't understand why this doesn't work. This might be a stupid question but I am really stuck.
I was also having this problem, trying to use llvm-sys on Windows. Here are some mistakes that I did that made it fail to compile just like yours.
Installation Prefix
Make sure that your LLVM installation path doesn't have any whitespace.
Mine was -DCMAKE_INSTALL_PREFIX=C:\Program Files (x86)\LLVM, which was their default install prefix. The whitespace in the installation path causes some errors when using it with llvm-sys. Later, I changed it to C:\LLVM and it worked.
Set Environment Variable
Set Environment Variable LLVM_SYS_<version>_PREFIX to the installed LLVM folder.
From CMD For LLVM-13.0.1
setx LLVM_SYS_130_PREFIX "<PATH TO LLVM WITHOUT WHITESPACE>" /M
Make sure that the variable is registered by using echo command
echo %LLVM_SYS_130_PREFIX%
It should output your registered path, not %LLVM_SYS_130_PREFIX%.
If it doesn’t output your path, restart the computer and try again and it should be working.
Now you should be good to go .....
Hope this helps :)
When stack run there is an error:
No setup information found for ghc-8.10.3 on your platform.
This probably means a GHC bindist has not yet been added for OS key 'macosx-aarch64'.
Supported versions: ghc-8.10.5, ghc-8.10.6, ghc-8.10.7, ghc-9.0.2, ghc-9.2.1, ghc-
9.2.2, ghc-9.2.3
But ghci works well, how is it possible to fix?
As you can see, m1 mac requires at least ghc-8.10.5, but you are using ghc-8.10.3. It may be because your project's stack.yaml specified ghc-8.10.3, try to change it to 8.10.7 to resolve it. Or select a lts version as an alternative(recommend).
From https://www.stackage.org/, LTS-18.28 uses ghc-8.10.7 as default.
Works for me:
In stack.yaml set resolver: ghc-9.2.3
Execute stack run under bash (exec bash in zsh terminal)
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 have working Eclipse (Kepler Service Release 2) + EclipseFP (2.6.0) + Haskell Platform under Windows 8.1 x64.
In one moment after some cabal install, EclipseFP stopped working and showing me:
The program ghc version >=6.4 is required but it could not be found.
I have:
Uninstalled Haskell Platform
Deleted C:\Users\myuser\AppData\Roaming\cabal*
Deleted C:\Program Files (x86)\Haskell*
Install Haskell Platform 2013.2
Run Eclipse with my Haskell workspace
Try to build my project
It gave me this error about ghc and cannot build it.
EclipseFP configuration found all Haskell Helper executables. It found Cabal 1.16.0.2 and GHC 7.6.3 already. From command-line GHC and cabal are found and are working. "cabal build" is working on the project from command-line, too.
This message doesn't say almost anything! If I could see the path it is searching for GHC or where it get this path from...
EDIT:
Message from buildwrapper:
"C:\Users\home\AppData\Roaming\cabal\bin\buildwrapper.exe synchronize --force=false --tempfolder=.dist-buildwrapper --cabalpath=C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe --cabalfile=D:\Project\haskell2\SomeGL\SomeGL.cabal --cabalflags= --logcabal=true
configuring because setup_config not present
"C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe" "configure" "--verbose=1" "--user" "--enable-tests" "--enable-benchmarks" "--builddir=D:\Project\haskell2\SomeGL.dist-buildwrapper\dist"
cabal.exe: The program ghc version >=6.4 is required but it could not be found."
Calling exactly the last line from cmd.exe (as normal non-admin user) everything is working fine:
"C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe" "configure" "--verbose=1" "--user" "--enable-tests" "--enable-benchmarks" "--builddir=D:\Project\haskell2\SomeGL\.dist-buildwrapper\dist"
EDIT:
To find the potential path environement that is used I tried to run GHCi console inside Eclipse and tried:
import System.Environment
x <- getEnvironment
filter (\ (a,_) -> a == "Path") x
and got something that is starting with:
[("Path","C:\Program Files (x86)\Haskell\bin;C:\Program Files
(x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin;C:\Program
Files (x86)\Haskell Platform\2013.2.0.0\bin;...")]
First folder is invalid, but Haskell Platform is valid and working.
Another thing I found. One of times I have run "Build All" command there was run Process in Eclipse with GHC and the path was:
Running executable C:\Program Files (x86)\Haskell
Platform\2013.2.0.0\bin\ghc.exe
I went to see this process details and it is run from the same user that is currently Eclipse run with. And the path is correct, but I still got the error:
The program ghc version >=6.4 is required but it could not be found.
Running from command-line still it is working. The program has errors, but only in command-line I see them.
Could someone help with finding this problem?
EDIT:
I found some interesting issue. Running "Build All" command is executing this command:
C:\Users\myuser\AppData\Roaming\cabal\bin\buildwrapper.exe synchronize
--force=false --tempfolder=.dist-buildwrapper --cabalpath=C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe
--cabalfile=D:\haskell\SomeGL\SomeGL.cabal --cabalflags= --logcabal=true
Which run from command-line gives an error. The problem is that there are no quotes around cabalpath, because it has spaces in it. When I run it that way from command-line it works:
C:\Users\myuser\AppData\Roaming\cabal\bin\buildwrapper.exe synchronize --force=false --tempfolder=.dist-buildwrapper --cabalpath="C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe" --cabalfile=D:\haskell\SomeGL\SomeGL.cabal --cabalflags= --logcabal=true
I think that all "--cabalfile" parameters should have quotes, because paths could have spaces in them. I still don't know if this is the problem under Eclipse.
I found the problem!
It is that EclipseFP 2.6.0 is using upper case "PATH" variable, but my Windows 8.1 use "Path" and programatically some kind it is possible to have valid two variables "PATH" and "Path" when executing BuildWrapper and Cabal. So something is messing up.
Workaround for this problem is if you rename from Control Panel | System | Environment variables for both User and System from "Path" to "PATH".
I hope this could be fixed in EclipseFP so it could in future work in any case.
Building your project means that under the scenes, cabal build is launched. If you activate the debugging mode in the Haskell helper executable preference page (show BuildWrapper responses), you should see the exact cabal build command being sent. It could be that the path used in Eclipse is different than the path used in the command line, check you eclipse shortcuts. EclipseFP can find the executables because it searches also in some well known folders on windows.
You can also take the current dev version of EclipseFP from github. It should now pass --with-ghc to cabal invocations to make sure the path detected in Eclipse is the one used.
I have two versions of python installed on centos 6.4. It came with python 2.6.6. I installed 2.6.2 in /home/python.
My PATH variable has 2.6.6 in the path(/usr/bin/python). So in the console when I type 'python' it loads 2.6.6.
but, if I change the LD_LIBRARY_PATH to add /home/python/lib and no change to PATH variable, when I type 'python' at the console, it loads 2.6.2.
My understanding of executable search order in linux is 'looks at PATH' to find it. So how come the change in LD_LIBRARY_PATH loads 2.6.2? May be understanding is wrong. Could somebody help me understand this behavior?
"python" is a stub executable which loads the Python interpreter from its library. You've told it to look at a different set of libraries first, and so it uses the one it finds there rather than its normal library.