Vim has support for Ruby commands. (For more information, please see the :help if-ruby documentation.) These commands can be run using :ruby if +ruby support is enabled (see vim --version). As an example, I can see that I'm currently using v3.0.0 by using:
:ruby print RUBY_VERSION
However, which Ruby installation is this? For example, is it system Ruby, something managed by RVM, or a separate Ruby installation that is built into Vim?
Also, is it possible to install Ruby gems to use with :ruby commands?
Details about my installation:
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.7
BuildVersion: 19H524
$ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 21 2021 06:59:54)
macOS version - x86_64
Included patches: 1-2625
Compiled by Homebrew
[...]
$ vim --version | grep ruby
+cursorshape +lua +ruby +wildmenu
Linking: clang -L. -fstack-protector-strong -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl#1.1/lib -L/usr/local/opt/readline/lib -L/usr/local/lib -o vim -lncurses -liconv -lintl -framework AppKit -L/usr/local/opt/lua/lib -llua5.4 -mmacosx-version-min=10.15 -fstack-protector-strong -L/usr/local/lib -L/usr/local/Cellar/perl/5.32.1_1/lib/perl5/5.32.1/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -L/usr/local/opt/python#3.9/Frameworks/Python.framework/Versions/3.9/lib/python3.9/config-3.9-darwin -lpython3.9 -framework CoreFoundation -lruby.3.0 -L/usr/local/Cellar/ruby/3.0.0_1/lib
$ which -a ruby
/Users/username/.rbenv/shims/ruby
/usr/bin/ruby
$ rbenv versions
system
* 2.6.5 (set by /Users/username/.rbenv/version)
All this depends on Vim build configuration. :ver output may indicate the following:
-lang interface for "lang" wasn't compiled at all;
+lang everything was statically linked into Vim executable;
+lang/dyn interface was linked against dynamic library (dll/so)
If it's linked dynamically then the library will be searched and loaded on demand by option value (e.g. :h 'rubydll'). In this case it may point to any installation you want. (Although -DRUBY_VERSION=XX specified at compile-time may still be relevant and Vim may fail to load mismatched library).
You don't mention your platform, or how you installed Vim. If we're talking about default behavior, these things matter.
Unless you statically compiled Ruby into Vim, it will be whichever Ruby is first in your PATH, or first in fish_user_paths if you use the fish shell. On macOS and typical desktop Linux distributions like Ubuntu, that's what you should expect out of the box.
Other ways to check include:
Using which -a ruby will show you all the rubies in your PATH.
If Ruby 3.0.0 is not the first item listed, or not the version installed to /usr/bin/ruby, then you can be pretty sure that something else is managing it.
Check env | fgrep -i ruby for settings from various Ruby managers.
Version managers usually work by modifying your environment. For example, chruby adds CHRUBY_VERSION to the environment, and RUBY_ROOT to set the path for the selected Ruby. Other common version managers will also update the environment in various ways, so this is a good place to look.
Check your shell initialization files (e.g. ~/.bashrc).
If you aren't setting up RVM, rbenv, or chruby in your shell's initialization script, then you probably aren't using one of them. Of course, that doesn't preclude the use of symlinks, GNU stow, or other redirections, but if you didn't set them up and aren't working on a multiuser system where someone else may have, then you can be pretty confident that invoking ruby is calling the Ruby that's first in your PATH.
Related
Mac 10.13.6 High Sierra here. New to C development and I'm trying to get myself setup with the latest stable/recommended GCC version, which I believe (keep me honest here) is 10.2.
When I go to the terminal to see what I have installed:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ gcc -dumpversion
4.2.1
OK...surprised to see LLVM/clang-related stuff in the output. So I try this:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
So its almost as if... I have both clang and gcc installed, but my clang installation has assimilated my GCC installation?! Why else would the gcc --version output reference clang?
Is this typical for Mac setups?
What do I need to do to get GCC 10.2 properly installed on my machine?
Here are some simple truths, statements and observations to try and explain what's going on:
Apple ships the clang/LLVM compiler with macOS. Clang is a "front-end" that can parse C, C++ and Objective-C down to something that LLVM (referred to as a "back-end") can compile
Clang/LLVM is located in /Applications/Xcode.app/somewhere
Apple also ships a /usr/bin/gcc which just runs clang. I have no idea why they do that - it doesn't seem very helpful to me - but they don't answer my questions
Apple puts its binaries (programs) in /usr/bin. That is an integral part of macOS and you should never touch or change anything in there - you are asking for problems if you do. This warning applies to Python too.
If you want the real, lovely GNU Compiler Collection (GCC) which includes the gcc, g++ and gfortran compilers, your best bet, IMHO, is to get them from homebrew. I will not put the installation instructions here because they could become outdated, so you should use the ones on the homebrew site.
Once you have homebrew installed, you can install the GNU Compiler Collection (GCC) with:
brew install gcc
After that, you will have all the lovely GNU Compiler Collection (GCC) of tools in /usr/local/bin, so you should put that in your PATH, near the beginning, and in any case before /usr/bin, using:
export PATH=/usr/local/bin:$PATH
In general, you should also add a similar line into your login profile, or into the system login profile, so it is set up every time you or any other user logs in.
Let's take a look:
ls /usr/local/bin/gcc* /usr/local/bin/g++*
/usr/local/bin/gcc-10
/usr/local/bin/g++-10
Depending on the versions and updates, you will then have these programs available:
gcc-10 # the real GNU C compiler
g++-10 # the real GNU C++compiler
gfortran # GNU fortran compiler
And you can check their versions with:
gcc-10 -v
g++-10 -v
gfortran -v
Now you know about homebrew, here are some more simple truths and observations:
folks (who are not the supplier of the operating system) who supply binaries (programs) for you should put their stuff in /usr/local to show that it is just a locally installed program rather than a part of the core macOS operating system
homebrew is well-behaved and installs its binaries (programs) in /usr/local/Cellar and then usually makes symbolic links from /usr/local/bin/PROGRAM to the Cellar. None of this interferes with Apple-supplied stuff.
if you want to run the homebrew version of a command, you should have /usr/local/bin first on your PATH
Let's have a look at those symbolic links:
ls -l /usr/local/bin/g*10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/g++-10 -> ../Cellar/gcc/10.2.0/bin/g++-10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/gcc-10 -> ../Cellar/gcc/10.2.0/bin/gcc-10
If you want to know what you are actually running when you enter a command, use the type command like this.
type gcc
gcc is hashed (/usr/bin/gcc)
That tells you that if you run gcc you will actually be running /usr/bin/gcc which we know is from Apple - because it is in /usr/bin
Now try this:
type gcc-10
gcc-10 is hashed (/usr/local/bin/gcc-10)
That tells you that if you run gcc-10 you will actually be running /usr/local/bin/gcc-10 which we know is from homebrew - because it is in /usr/local/bin
I have XCode installed (Version 7.2.1 (7C1002)) in Yosemite and have downloaded and installed command line tools. When I try to check the gcc version I get:
$ gcc -v
Segmentation fault: 11
$
The output for:
$ type -a gcc
gcc is /usr/local/bin/gcc
gcc is /usr/bin/gcc
$
From what I understand, that should mean that I have it installed so I still don't understand why I can't check it's version. Since I will need gcc for other applications I would like to have it fixed...any suggestions? Do I need to link it somehow?
You have a faulty third-party version of gcc (or perhaps another compiler masquerading as gcc) installed in /usr/local. This may be something put there by Homebrew or maybe you installed this build of gcc yourself or something.
A short-term fix would be to modify your PATH environment variable so that /usr/bin comes before /usr/local/bin. Or, you could just always specify the full path to gcc, such as /usr/bin/gcc -v.
Longer term, you probably want to remove the broken gcc that's been installed to /usr/local. How you do that exactly depends on how you originally installed it there.
I somehow lost the man pages for gcc and g++. I'm not sure where/what to look for. I'm pretty sure the man pages used to work some time ago. It also works on my Mac at work where I use roughly the same setup. Could it be a problem with brew? Or is it a bug in the XCode Command Line Tools?
Update: I just tried to re-install the XCode Command Line Tools. No luck.
~
✓ man gcc
No manual entry for gcc
~
✗ which gcc
/usr/bin/gcc
~
✓ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
gcc isn't installed anymore by Xcode, it really installs clang and calls it gcc
usxxplayegm1:~ grady$ which gcc
/usr/bin/gcc
usxxplayegm1:~ grady$ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.0.2
Thread model: posix
you need man clang
I thought it was a symlink, but ls -l doesn't list it as a symlink, so either it is a hard link or some other sort of trickery.
This may be old and doesn't quite answers your concrete question, but I found myself in the same problem with Kali Linux and I solved it with this command, maybe is useful for someone:
apt install gcc-doc
Look at how you set MANPATH in your .profile. Instead of, e.g.,
export MANPATH=/opt/local/man:/usr/local/man
you should do
export MANPATH="/opt/local/man:/usr/local/man:$MANPATH"
And then (breathe) open a new Terminal window.
This way your .profile isn't wiping out (or reflecting an old version of) the system's way of setting MANPATH, which is modified when you install (or reinstall) Xcode.
I use High Sierra with g++ 7.2 port. Setting MANPATH environment to /opt/local/man (or to /opt/local/man/man1 where g++.gz is found) did not work. So, after ensuring that the soft link g++.gz points to g++-mp-7.1.gz (there was not a g++-mp-7.2.gz in the man1 directory though g++7.2 is my version), I always use the command:
man /opt/local/share/man/man1/g++.gz
that never fails. You can store an alias for this in your .profile, if you are frequently using the man command for g++.
For anyone who stumbles upon this currently (like I did), I found that I needed to locate my version of gcc (which I had installed with brew). This is annoying when gcc --version gives the clang version instead! To find the correct gcc version, run
$ ls /usr/local/opt/gcc/bin | grep gcc
gcc-10
gcc-ar-10
gcc-nm-10
...
So I had gcc-10. Whenever you wish to use gcc just replace it with gcc-10, e.g. man gcc-10. Of course you could write an alias for gcc to gcc-10, but this probably is not a great idea, as Xcode seems to rely on the gcc --> clang (hard?) link.
I'm trying to install GalSim on OSX Mavericks, using the anaconda python distribution, but keep running into the error:
Unable to build a python loadable module using the python executable:
/usr/bin/env python,
the library name libpython2.7.a,
and the libdir /Users/harrison/anaconda/lib/python2.7/config.
If these are not the correct library names, you can tell scons the
correct names to use with the flags EXTRA_LIB_PATH and/or EXTRA_LIBS.
the /usr/bin/env python is the anaconda one and there is indeed a libpython2.7.a in that libdir.
scons is installed via the conda package management system.
boost is installed manually as recommended via
./bootstrap.sh --with-python=/Users/harrison/anaconda/bin/python --with-python-root=/Users/harrison/anaconda/
./b2 -a link=shared
sudo ./b2 -a --prefix=/usr/local link=shared install
checking the version of python boost links to gives
$ otool -L /usr/local/lib/libboost_python.dylib
/usr/local/lib/libboost_python.dylib:
libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
libpython2.7.dylib (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
Is this correct (it doesn't seem so to me -- boost seems to be linking to the libpython2.7 in /usr/local/) and is this what is causing the problem installing GalSim?
Thanks
Ian
Full output:
$ scons
scons: Reading SConscript files ...
SCons is version 2.3.0 using python version 2.7.6
Python is from /Users/harrison/anaconda/include/python2.7
Using the following (non-default) scons options:
CXX = g++
These can be edited directly in the file gs_scons.conf.
Type scons -h for a full list of available options.
Using python = /usr/bin/env python
Using default PYPREFIX = /Users/harrison/anaconda/lib/python2.7/site-packages
Using compiler: /usr/bin/g++
compiler version: 4.2.1
Determined that a good number of jobs = 4
Checking for C++ header file fftw3.h... yes
Checking for correct FFTW linkage... yes
Checking for C++ header file boost/shared_ptr.hpp... yes
Checking for C++ header file TMV.h... yes
Using TMV_LINK file: /usr/local/share/tmv/tmv-link
-L/usr/local/Cellar/tmv-cpp/0.71/lib -ltmv -lblas
Mac version is 10.9
WARNING: The Apple BLAS library has been found not to be thread safe on
Mac OS version 10.7 (and possibly higher), even across multiple
processes (i.e. not just multiple threads in the same process).
The symptom is that `scons tests` will hang when running nosetests
using multiple processes.
If this occurs, the solution is to compile TMV either with a
different BLAS library (e.g. ATLAS) or with no BLAS library at
all (using WITH_BLAS=false).
Checking for correct TMV linkage... (this may take a little while)
Checking for correct TMV linkage... yes
Checking if we can build against Python...
Unable to build a python loadable module using the python executable:
/usr/bin/env python,
the library name libpython2.7.a,
and the libdir /Users/harrison/anaconda/lib/python2.7/config.
If these are not the correct library names, you can tell scons the
correct names to use with the flags EXTRA_LIB_PATH and/or EXTRA_LIBS.
Please fix the above error(s) and rerun scons.
Note: you may want to look through the file INSTALL.md for advice.
Also, if you are having trouble, please check the INSTALL FAQ at
https://github.com/GalSim-developers/GalSim/wiki/Installation%20FAQ
Ian, thanks for posting that. Based on the config.log and my own experience, I have an answer that should solve at least this problem (no guarantees that you won't hit something else later in the build).
The key problem here is that if you tell it the compiler is gcc (as is the default), it will try to use openMP. But actually invoking gcc on Mavericks gives you clang++, for which openMP doesn't work. So, you have to explicitly tell galsim that the compiler is clang++ so it won't try to use openMP. (The clue to this is in config.log, there are messages in various places about undefined symbols for x86_64 architecture... I had this problem on my own system when I started using Mavericks. See also https://github.com/GalSim-developers/GalSim/issues/493 )
So, please do scons CXX=clang++ and this problem should go away. I cannot guarantee that you won't hit a boost problem later on, however.
Please also see this question which has two suggestions which may help solve the problem for you as well.
In OS X, how can I link gcc-4.8 from homebrew to gcc? I already tried to link gcc-4.8 to /usr/local/bin/gcc but this does not work. I really need this because I have shared makefiles in a course at the university.
There are at least a couple of options.
I have my GCC 4.8.2 installed under /usr/gcc/v4.8.2 and I ensure that /usr/gcc/v4.8.2/bin is on my PATH ahead of /usr/bin. That way, the undecorated name gcc means GCC 4.8.2. (This is on Mac OS X 10.9.1 Mavericks, just for the record.)
Specify CC=/usr/gcc/v4.8.2/bin/gcc on command lines, etc. Painful, so I don't regard it as a real option.
Make /usr/bin/gcc point to /usr/gcc/v4.8.2/bin/gcc instead of being an executable that runs clang.
I distrust modifying /usr/bin or /bin (or /sbin or /usr/sbin). I seldom use the system-provided Perl, for example, but always use my own build, using the same general technique.