unable to execute 'x86_64-conda_cos6-linux-gnu

问题:

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.

回答1:

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.

回答2:

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

回答3:

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

回答4:

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...