With spack, I am trying to install a package using a previous install of openmpi#3.1.5.
And I get the following error during concretization:
Error: trying to set variant "wrapper-rpath" in package "openmpi", but the package has no such variant [happened during concretization ... ]
Indeed if I do a spack info openmpi there is no wrapper-rpath but a runpath variant instead.
Therefore, I manually changed the spack-db/index.json to put runpath instead of wrapper-rpath in the openmpi variants. The concretization is therefore succesfull but during installation I hit the following :
Error: Specs openmpi#3.1.5%gcc#7.3.1 ... +runpath + ... and openmpi#3.1.5%gcc#7.3.1 ... + wrapper-rpath + ... have the same SHA-1 prefix!
So my understanding is that the change of variant name results in a new SHA1, and I should change this SHA1 everywhere.
First, am I right that the name of the variant has been changed? Second, is there a simple way to update the database accordingly and keep using the already installed package ?
With thanks !
First, am I right that the name of the variant has been changed?
Yes, the variant name was changed in https://github.com/spack/spack/pull/17073
Second, is there a simple way to update the database accordingly and keep using the already installed package?
Unfortunately not. You can either rebuild openmpi, or you can explicitly link to it using its hash. See spack find -l openmpi to find the hash. Then use it like spack install foo ^/hashofopenmpi.
Related
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...
Every time I try to build bluez I get the error:
dh_install: libbluetooth3 missing files (usr/lib/*/libbluetooth.so.3), aborting
Looking in my own path I see that the currently installed version of the library is located at:
/usr/lib/x86_64-linux-gnu/libbluetooth.so.3
But the build script (fakeroot debian/rules binary) keeps putting the output into usr/lib/libbluetooth.so.3.
To specify the correct folder you need to declare the environment variable DEB_HOST_MULTIARCH and use the binary-arch target (though binary may suffice as documentation suggests binary calls both binary-arch and binary-indep):
DEB_HOST_MULTIARCH=x86_64-linux-gnu debian/rules binary-arch
The value was chosen based off of the current install path of libbluetooth.so.3 (/usr/lib/x86_64-linux-gnu/libbluetooth.so.3) and could possibly change if the Debian distribution you're running places 64bit binaries elsewhere.
I think I have a gem installed twice but I don't know how to uninstall one of them. When I try to build my rubymotion project I get these warnings:
/Users/pachun/.rvm/gems/ruby-1.9.3-p194#global/gems/bundler-1.2.1/lib/Bundler.rb:12: warning: already initialized constant ORIGINAL_ENV
/Users/pachun/.rvm/gems/ruby-1.9.3-p194#global/gems/bundler-1.2.1/lib/Bundler.rb:64: warning: already initialized constant WINDOWS
/Users/pachun/.rvm/gems/ruby-1.9.3-p194#global/gems/bundler-1.2.1/lib/Bundler.rb:65: warning: already initialized constant FREEBSD
/Users/pachun/.rvm/gems/ruby-1.9.3-p194#global/gems/bundler-1.2.1/lib/Bundler.rb:66: warning: already initialized constant NULL
And regular builds still work, but I think this is causing my test suite (frank cucumber) to fail.
How can I fix this? Thanks
The easiest way to remove all gems and reinstall using rvm is do this:
rvm gemset empty <gemset name>
bundle
Instead of doing that, I would recommend you make a .rvmrc file and put the following:
rvm use 1.9.3#projectname --create
Save the file to your project folder and then cd out and back in to the folder, answering "Y" to the question of whether to load the .rvmrc file. This will switch you to a new (empty) gemset and you can re-run bundle.
I have been banging on this for hours now.
I am trying to push my repo changes to kiln but I get this error:
certificate checking requires Python 2.6
I have already installed a parallel install of Python 2.6 by following the instructions from this link, but the error still persists. The system is ClearOS 5.2 by the way.
My first question is, will installing/upgrading mercurial break my existing install?
I tried to re-install following these intstructions link1 and [i lost the other link], but encountered another error.
Then I found this command debuginstall and here's the result:
[root#system mercurial-1.7.5]# hg debuginstall
Checking encoding (UTF-8)...
Checking installed modules (/usr/lib/python2.4/site-packages/mercurial)...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
no username supplied (see "hg help config")
(specify a username in your configuration file)
1 problems detected, please check your install!
My another question is, can I just change the existing hg's settings to just use the python26 which is already installed?
Thanks in advance!
Install your own python (of whatever version you need) to a separate directory (e.g.: /usr/local/python-2.7.2/) and then change the invocation of hg from #!/usr/bin/python to #!/usr/local/python-2.7.2/bin/python This way you don't disturb the existing/system installation, but you can use the version you want only where you need it. The only annoying part about this is dealing with two sets of libraries, since this is really maintaining two parallel installations. So if the 'extra' python needs libraries, you must install them manually using the invocation and paths of the extra installation. Sounds complicated, but if you only need it for one program, then you set it up once and it's good to go.
Nowdays I'm just trying to build libsamperate from source using MSYS on Windows, but i meet a configure checking problem I've installed FFTW & libsndfile before, their include files lib files and pkg-config files are all in the right place, but when I use sh ./configure to generate makefile for libsamprate the output always mentions
checking for pkg-config... no
checking for SNDFILE... no
I also set the PKG_CONFIG_PATH(usr/local/lib/pkgconfig) and tried many times but the result seems the same
Does anyone knows anything about this?
As mentioned in comments, your environment is not set up to run the pkg-config executable. There are many problems associated with pkg-config, and it has become increasingly popular to suggest that the correct solution is to stop using it completely. Unfortunately, if you are trying to install a package that does use pkg-config, you are not in a position to use that solution. The closest you can get is to set PKG_CONFIG to 'true' or ':' in your environment. This causes pkg-config to emit no output but always return true when it is run, so you need to specify locations of libraries and headers via the standard mechanisms (LDFLAGS, etc.).
pkg-config is great in that it allows a user (someone installing the package) to be ignorant of the standard flags. The problem with pkg-config is that it allows the users to be ignorant.
As a package maintainer, you should stop using pkg-config. As a user, you should either set PKG_CONFIG=: in your environment or in a config.site, or get in the habit of invoking configure with PKG_CONFIG=: as an argument. (If you are using packages that rely on ancient autoconf in which you cannot pass such flags as an argument, I'm not sure what the appropriate action is, but suggesting that the package maintainer upgrade is probably not a bad idea.)