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.
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 :)
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...
Firstly, I am new to Linux so excuse me if any terminology is wrong; I'll try to phrase the problem as competently as possible.
I have installed Ruby (2.4.0) via Linuxbrew. The ruby command works fine; it installed correctly. However, when I try to use the gem command (which Ruby should have installed) I receive this error:
bash: /usr/bin/gem: No such file or directory
Now, because I installed this with Linuxbrew I know that this directory isn't correct. For example:
result of which gem : /home/me/.linuxbrew/bin/gem
result of which ruby : /home/me/.linuxbrew/bin/ruby
Therefore, it seems gem is installed but the gem command isn't linked to the correct path. I assume I need to direct the gem command to the path of which gem as opposed to /usr/bin/gem that bash is saying doesn't exist. How would I go about changing this? I tried in vain to change the bash_profile but I'm not sure what to do.
Again, excuse me if ruby and gem are not referred to as commands and if the problem isn't the "default directory" as stated in the title. I wasn't sure how to label it.
EDIT/TL;DR:
Basically, how can I make gem execute this: /home/me/.linuxbrew/bin/gem instead of looking for the program in /usr/bin/gem?
Instead of running gem, run /home/me/.linuxbrew/bin/gem, i.e. type the full path name (followed by any arguments you may need).
If this becomes too tiresome, you could change your PATH. Prepend your bin directory with
PATH=$HOME/.linuxbrew/bin:$PATH
First, the reason you get the error /usr/bin/gem not found, is that earlier in the same shell session, the file used to be there. Bash will cache this to speed things up when running the same command many times. Running hash -r will clear this.
Editing PATH you seem to have managed, hence the which command gives the result it does.
To answer my own question-
As I had previously installed and uninstalled Ruby via apt-get instead of Linuxbrew in the same Terminal window, Bash was looking for gem in usr/bin as opposed to the path specified in my bash_profile to Linuxbrew.
Therefore, Stian's answer above with hash -r would also work, I am sure.
I am using ubuntu 12.04. Every time I start my bash terminal and every time when I finish typing a command(and press enter) , I get this message:
ERROR: ld.so: object '/usr/lib/liblunar-calendar-preload.so' from
LD_PRELOAD cannot be preloaded: ignored.
It is weird.
So what is the environment variable LD_PRELOAD used for? And what is the going on behind the scene?
Thanks.
The linker takes some environment variables into account. one is LD_PRELOAD
from man 8 ld-linux:
LD_PRELOAD
A whitespace-separated list of additional, user-specified, ELF
shared libraries to be loaded before all others. This can be
used to selectively override functions in other shared
libraries. For setuid/setgid ELF binaries, only libraries in
the standard search directories that are also setgid will be
loaded.
Therefore the linker will try to load libraries listed in the LD_PRELOAD variable before others are loaded.
What could be the case that inside the variable is listed a library that can't be pre-loaded. look inside your .bashrc or .bash_profile environment where the LD_PRELOAD is set and remove that library from the variable.
If you want to make sure that the library is loaded if and only if the program lunar-calendar-gtk is launched, you can apply this:
You set the environment variable per command by prefixing the command with it:
$ LD_PRELOAD="liblunar-calendar-preload.so" printenv "LD_PRELOAD"
liblunar-calendar-preload.so
$ printenv "LD_PRELOAD"
$
You can then choose to put this in a shell script and make lunar-calendar-gtk a symlink to this shell script, replaceing the original referencee. This effectively makes sure that the library is loaded everytime the original application is executed.
You will have to rename the original lunar-calendar-gtk to something else, which might not be too intriguing as it possibly may cause issues with uninstallation and upgrading. However, I found it useful with a former version of Skype.
Thanks for the responses. I think I've solved the problem just now.
Since LD_PRELOAD is for setting some library proloaded, I check the library that ld preloads with LD_PRELOAD, one of which is "liblunar-calendar-preload.so", that is not existing in the path "/usr/lib/liblunar-calendar-preload.so", but I find a similar library "liblunar-calendar-preload-2.0.so", which is a difference version of the former one.
Then I guess maybe liblunar-calendar-preload.so was updated to a 2.0 version when the system updated, leaving LD_PRELOAD remain to be "/usr/lib/liblunar-calendar-preload.so". Thus the preload library name was not updated to the newest version.
To avoid changing environment variable, I create a symbolic link under the path "/usr/lib"
sudo ln -s liblunar-calendar-preload-2.0.so liblunar-calendar-preload.so
Then I restart bash, the error is gone.
It means the path you input caused an error. In your LD_PRELOAD command, modify the path like the error tips:
/usr/lib/liblunar-calendar-preload.so
I got this type of error when I installed Citrix client on my Raspberry Pi. In short there is a file /etc/ld.so.preload. The library my system was complaining about was listed in that file. I commented it out with a # and system stopped complaining.
The solution that worked for me was using sudo vim and going into /etc/ld.so.preload
I then just removed the line
/usr/local/lib/AppProtection/libAppProtection.so
Then I just saved the file and everything worked without issues.
When I executed the following command, everything became better.
unset LD_PRELOAD
You can check /etc/ld.so.preload file content
I fix it by:
echo "" > /etc/ld.so.preload
I installed libffi-3.0.11, because another program needs that. But after the installation the other program (by calling the comand ./configure)don't recognize that libffi is installed. Do I have to set a environment variable? Or are all variables set automatically?
usually there is a LIBPATH, you should try to include the directory where your lib resided into this path. In addition, if you have a default bash
export LIBPATH=/your/libffi/path:$LIBPATH
I highly recommend to put this into a script and load it whenever you login automatically so that you don't need to repeat this step
/home/yourhome/.profile <- make sure you insert it into this file and its loaded automatically
Here is a guide how to do the task:
http://archive.linuxfromscratch.org/lfs-museum/5.1-pre1/LFS-BOOK-5.1-PRE1-HTML/chapter06/glibc.html
The parameter you probably need is the following:
./configure --libexecdir=/usr/lib:
If you have installed the libffi library properly this should completely solve your problem.
It depends, if you install libffi on /usr/local you should probably set the includes dir of the app you want to configure to /usr/local.
For the new app, try ./configure --prefix=/usr/local. To see the options of configure, use ./configure --help. Can you show the example of what is not running ?