I installed YouCompleteMe for VIM via Vundle on my Mac with Mavericks. After Vundle did its magic i ran
./install.sh --clang-completer
which worked without any errors. The Python completion works fine, too. But the C Lang Family support does not seem to work. Also running
./run_tests.sh
gives me
Your C++ compiler supports C++11, compiling in that mode.
-- Found PythonLibs: /usr/local/Cellar/python/2.7.7_2/Frameworks/Python.framework/Versions/2.7/Python (found suitable version "2.7.7", minimum required is "2.6")
NOT using libclang, no semantic completion for C/C++/ObjC will be available
Does anybody know how to solve that problem?
Don't run the 2nd command
./run_tests.sh
It's will re-compile ycm_*.so without --clang-completer (that is default option).
To fix it, install again:
./install.sh --clang-completer
add your clang_library_path in .vimrc,such as
let g:clang_library_path='/usr/lib/llvm-3.8/lib/'
Related
I recently moved from the SGI, Sun workstation environment to a Mac. SGI and Sun came with Fortran compilers so I have maybe 100 small f77 codes I wrote over the years for post-processing and analysis of simulated data. I was hoping to get these codes running on my iMac with gfortran. Most of these are very simple codes but I can't get them to compile and execute. I tried starting with the basics and wrote the Hello World code from a gfortran help page. My code, fortran.f is:
program helloworld
print *, "hello world"
end program helloworld
When I tried compiling this according to the example I typed:
gfortran fortran.f
But I keep getting the error message:
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
This is the same error message I get on my other codes. Can someone tell me what I'm doing wrong? I can't think of a simpler example but I can't seem to get it to work.
When it comes to macOS, I think that building form sources is the best approach you can have. You can achieve that quite easily by downloading and compiling GFortran as part of GCC directly from: https://gcc.gnu.org/wiki/GFortran
However, there are few things you have to take care of:
make sure you have XCode installed, you can get it here
XCode
XCode is free of charge
Make sure you have command line tools
You can get them either from developer.apple.com
Command Line Tools
or directly from XCode. It might be that XCode will tell you to install Command Line Tools upon first execution
In the past, running command like "svn", when Command Line Tools were not installed, also triggered the installation.
Compile GCC
> ./configure --prefix=$HOME/opt/usr/local
> make all
> make install
Alternatively, you can install using macOS package from GFortran
gfortran-6.3-Sierra.dmg
Fully working sample with Fortran based MPI code:
http://www.owsiak.org/running-open-mpi-on-macos/
If your gfortran was installed a long time ago and you have updated macOS since installing, it may need re-installing to get correctly aligned and linked with the latest macOS tools and libraries.
My advice would be to:
uninstall gfortran,
check that Xcode and its command line tools are up-to-date,
re-install gfortran.
Hints for each of those steps follow:
Note that gfortran is a part of GCC - the "GNU Compiler Collection".
If you installed gfortran via homebrew, you can remove it with:
brew rm gcc
You can update Xcode by by going to AppStore and clicking Updates at top-right.
The Xcode Command Line tools include make and git and command-line versions of the compilers. You can install/update the Xcode command line tools with:
xcode-select --install
You can install gfortran with homebrew using:
brew install gcc
When you are finished, you should make sure that your PATH includes /usr/local/bin near the start and that there are no errors when you run:
brew doctor
which is a brilliant utility that checks your homebrew configuration is correct.
All I had to do was change the path.
Initially, my PATH was something like
/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin
Because of this reason, the default assembler (as) was not called which is in the /usr/bin directory.
To enable the call to the right assembler (as), I had to add /usr/bin to the PATH in front of (before) /opt/local/bin, i.e. on a Mac this can be added by editing ~/.bash_profile such that one's $PATH looks like
/usr/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin
Once edited, execute at your command prompt:
source /etc/bash_profile
This worked for me.
I've been struggling for 2 days to install some plugins which use python on Vim (Windows). Even with a stock vimrc.
Using the official vim 7.4 binary (x86)
I've checked that it comes with +python/dyn and +python3/dyn
I've installed Python 2.7.10 x86, and appended python's path in my Path environment.
:echo has('python') prints 1 as expected.
Yet: when I type :python print 'test', vim quits, just as if I've typed :q
:python mum tell me, why does windows exists?, it quits as well. Wondering why... Not a print issue at least.
Using tuxproject's nighty builds of vim 7.4.826 (x86)
It does come with +python/dyn and +python3/dyn. Also:
Used libraries: Perl 5.22.1, Python 2.7.10, Python 3.4.3, Ruby 2.2.3, Lua 5.3.0, Tcl 8.6.4, libXpm.
Great! That's the verison I've downloaded (2.7.10) ! Wait...
:echo has('python') prints 1 as expected.
But, "merry christmas!" says vim.
Sorry, this command is disabled, the Python's site module could not be loaded. Windows isn't good enough. Oh, and merry christmas!
Using tuxproject's nighty builds of vim 7.4.826 (x64)
I tried to use x64's python binary, taking care of removing the x86 version from my Path variable. Same issue as above.
Using Kaoriya's vim 7.4.something (x64) and Veegee's vim 7.4.803
Same issue as above.
What about compiling vim ?
Windows.
I'm not that lazy, well, yes I am... but I'll try to compile it if there isn't any other workaround. I don't really want to compile it if it won't solve anything. If only I could at least understand why these issues happen...
All right, I managed to solve the issue.
For those who may be interested, the intended python version was Python 2.7.9 and not 2.7.10. Installing Python 2.7.9 x86 (and x64) fixed everything for the corresponding vim version.
First of all, need to check for the python version compiled into the vim. One of the way is to edit the gvim executable (e.g. for window it's gvim.exe), and look for "python\d*.dll\c" as mentioned inside the vim manual. Nonetheless, when you run :echo has('python3') || has ('python'), it may give you the hint that vim cannot find and load python27.dll or python32.dll, so you can guess the python get compiled with vim in this way as well.
Once you have identified the python version needed, and if your python is installed on another location, then you can specify the pythonthreedll location to let vim to find it.
:set pythonthreedll=D:\installed\python\python35.dll
check again with following:
:echo has('python3')
I have this problem too but I didn't have to install previous versions.
All I do to solve this is just set PYTHONHOME=C:\Users\MYUSERNAME\Anaconda2 in my system environment variables!
You may have to adjust the location if you did not use Anaconda as a python installer.
Note: I use python 2.7.11 and 3.5 (Both of them are installed via Anaconda 64-bit)
PS. Please ensure that PYTHONHOME is typed correctly, no underscores. And it should point to the location of Python 2 only. Don't point to Python 3 folder.
PPS. It turns out that if you set PYTHONHOME, your working python3 command on the terminal will crash, so I do not suggest this anymore.
[I am not sure whether this fits here or should be moved to apple.SE]
Today I got the idea to recompile my vim in order to get the latest updates. I have once or twice before followed the suggestion in this answer so I did it again. I cloned the repo and ran
./configure --prefix=/opt/local/ --with-features=huge
(I tried with no options, problem persists)
Invariably, compilation aborts when the compiler attempts to parse ObjC-Files (for whatever reason it has to)
/usr/include/objc/NSObject.h:22:4: error: unknown type name 'instancetype'
- (instancetype)self;
It seems the compiler does not know the current Objective-C standard.
There seems to be a problem with gcc because I found this bug ticket. However, the most recent update on this is from last year.
Can someone suggest a way to make this work?
EDIT: I know I could install it via homebrew or macports; yet I am still very curious how to fix this particular problem.
Also I tried manually changing the compiler to clang like so
CC=clang ./configure --prefix=/opt/local/ --with-features=huge
After simply setting CC=clang before running (which is what the configure help seems to advertise) and seeing it did nothing. However when specifying a compiler this way (I tried the same with gcc as well), many configure checks turn out no and it eventually aborts.
I am assuming that gcc has not been configured with Objective-C support (it supports at least C, C++ and Objective-C and the installer can opt for whatever support they want).
It's possible that the 3rd-party clang is in the same boat. However I know that the Xcode version supports all 3 languages and will pick-up the correct OSX Cocoa runtime libraries, so using that appears to have solved the issue:
$ CC="xcrun clang" ./configure --prefix=/opt/local/ --with-features=huge
However just using clang should have worked as well, if which clang returns /usr/bin/clang as you say it does, so I'm at a loss to explain exactly why that didn't work.
So this is after having dropped $30 for Mac OS 10.7 and having downloaded XCode 4.3.2. After installing the command line tools, the installed version of gcc is still 4.2.4. I need 4.7. I've installed it and set the g++ link in /usr/bin to it. But when I try to compile any program via QtCreator, I get
unrecognized command line option -Xarch_x86_64
I found this discussed in a 3-year-old bug report here, but I really couldn't follow all the different shell commands etc. and my attempt to install liblastfm failed with the same error. The comment here,
The problem is that the GCC/G++ that is normally used to compile stuff
on Macs is actually just a wrapper.
And this wrapper has Mac-Only arguments like -Xarch_x86_64, which then
get converted into the correct args.
Seems like it might be hitting the nail on the head. Aaargh! Surely there has to be some way to get around this?
I created a custom makespec - in QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs, I copied the macx-g++ folder to macx-g++47. I then removed the "include(../common/g++macx.conf)" from that and included it's contents, except for the part that generates the error (i.e. the -X... thing).
I also finished with
QMAKE_CC = gcc-mp-4.7
QMAKE_CXX = g++-mp-4.7
QMAKE_LINK = $$QMAKE_CXX
QMAKE_LINK_SHLIB = $$QMAKE_CXX
QMAKE_LINK_C = $$QMAKE_CC
QMAKE_LINK_C_SHLIB = $$QMAKE_CC
...which is similar to the spec for macx-g++42.
Now, if I add '-spec macx-g++47' to the qmake args, it works.
A lot of effort for something simple...would love to know a better way.
There are several sources for newer gcc versions for OSX. Here is a small selection:
http://hpc.sourceforge.net/ (currently gcc 4.8, previous versions might also be available)
http://gcc.gnu.org/wiki/GFortranBinaries (has gcc 4.7.0 binary installer)
I assume that you did install the command line tools from within Xcode. Apple/Xcode is not always up to date with gcc, stability is more important here than bleeding edge.
I have been trying to build ECL under OS X 10.7 and I have been
running into trouble. When I try building it I end up getting a
segfault on the ecl_min stage.
I configure with the following line:
./configure --build=x86_64 --target=x86_64 --prefix=`pwd`/install_ecl
CC=/Developer/usr/bin/gcc-4.2
And the compile fails with:
if [ -f CROSS-COMPILER ]; then \
./CROSS-COMPILER compile; \
else \
ECLDIR=`pwd`/ ./ecl_min compile; \
fi
/bin/sh: line 1: 17433 Segmentation fault: 11 ECLDIR=`pwd`/ ./ecl_min compile
I have tried building gmp and boehm-gc externally and not using the
included ones, but unfortunately it ended up with the same results. I
have also tried the default llvm-gcc without much luck either.
Has anyone been able to compile ECL under Lion, and if so, what configure options / patches did you need to apply.
Update:
I was able to compile thanks to the accepted answer below. Here is the scripts that I used (Note: This is from a fresh git clone of ECL):
#!/bin/sh
ECL_INSTALLDIR="`pwd`/install_ecl"
mkdir -p $ECL_INSTALLDIR
./configure\
--prefix=$ECL_INSTALLDIR\
--enable-boehm\
--enable-unicode=no\
CC=/Developer/usr/bin/gcc\
CXX=/Developer/usr/bin/g++\
CFLAGS="$CFLAGS"
LDFLAGS="$LDFLAGS"
make && make install
This problem has been fixed in git/CVS. As explained above, the cause for the miscompilation was the version of our garbage collector: we shipped the last one available: 7.1, but this does not work with OS X Lion. ECL now ships with two versions (7.1 and 7.2-cvs), using the newest one in OS X Lion. In other words, ECL from git/CVS (http://ecls.sourceforge.net/download.html) should compile and run out of the box.
This page describes the two causes of the problem (an issue with the compiler, and an issue with garbage collector compatibility), and offers a temporary solution until the issue itself is fixed. The instructions come down to:
Download a new build of the Boehm-Weiser garbage collector library, apply a patch (you can get a link to download both the library and the patch from that page as well), and install it somewhere
Configure ECL with these extra options:
--enable-boehm=system
CPPFLAGS=-I/location/for/library/include
LDFLAGS=-L/location/for/library/lib
Where /location/for/library is the prefix you used to install the garbage collector.
And then it should build properly.
I also found this MacPorts ticket which seems to be tracking this issue; check there for future updates to see if it will be fixed.