Case: Testing clang_complete with gVim 7.3
I installed MinGW, then followed the tutorial here to download and compile clang. It compiled for around an hour, then make install. Clang worked. I especially love the error annotation. It's amazing.
Now comes the case of clang_complete. I Installed it. I am using pathogen, so clang_complete fron github comes in bundle folder inside vimfiles.
I opened the vim editor and gave command :scriptnames. It shows clang_complete plugin. :version shows it has python entry, so vim was built with python support.
Also my test system has python installed.
but whenever I issue :save foo1.cpp , vim give this error,
Error detected while processing function 14_ClangCompleteInit..14_initClangCompletePython:
line2
clang_complete:No python support available
line 3
cannot use clang library.
simply puzzled.
*I have python installed on my system.
I Also tried using libclang library path for clang_complete as mentioned in another question on clang_complete here, but to no avail.*
Thank you.
Vim needs to be compiled with Python support, i.e. +python when doing :version. -python means it's not installed. Taken from clang_complete at Github:
You need Vim 7.3 or higher, compiled with python support and ideally,
with the conceal feature.
You said you had this enabled, but it doesn't look like it. Taken from clang_complete.vim.
This is the only place that error message is defined and triggers on !has('python'). In other words this doesn't seem to be a clang_complete issue, but rather that your install is missing or is having problems with Python support.
function! s:initClangCompletePython()
if !has('python')
echoe 'clang_complete: No python support available.'
echoe 'Cannot use clang library'
echoe 'Compile vim with python support to use libclang'
return 0
endif
[..]
Just came across this issue, invoking :version returns for features:
-python
+python3
So it seems this is caused by incompatible plugin that requires python (e.g. 2.x) but only python 3.x is available.
Related
I'm running clang on mac to compile a c file created by running a very simple program through cython, but the compiler always give me a "Python.h not found" fatal error. I've tried every solution I could find, reinstalling python 3.9, using the -I/path/to/headerfile method, and rewriting the include statement in the code to contain the full filepath, but nothing has worked. When I do include the full filepath, I get fatal error: 'cpython/initconfig.h' file not found. What could the issue possibly be, and how would I fix it? The program itself works fine in the standard python interpreter, pyinstaller, and nuitka.
Today I needed to embed Python into a C application developed on XCode with Clang compiler, and I've met the same problems and solved them. Let me share the tips:
1. Python not found error
You should install a Python framework to your MacOS, and attach it into Frameworks and Libraries project settings tab. Also, specify it's path in Framework Search Paths inside Build Settings tab if XCode hasn't done it automatically.
2. Undefined symbols / Implicit declaration errors
Verify you're using a modern version of Python framework. Versions prior to 3.6 had different ABI which leads to the mentioned errors.
3. cpython/initconfig.h file not found
Versions prior to ~3.9 had some header inclusion problem for the cpython/initconfig.h file (issues 40642, 39026).
Check the builds of Python that your OS currently has. I found Pythons installed in the following paths:
# Default 2.7 MacOSX installation is here
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/
/Library/Frameworks/
Or install a recent Python version. I recommend using "universal binary" build, see the docs.
I'm developing a Python binding for a C++ library using Boost Python, for Linux and Windows (Visual Studio).
In Windows, the static Boost Python library has a dependency against Python (this is motive for another thread, here), so, in my CMake config I need to do:
if((${CMAKE_SYSTEM_NAME} STREQUAL "Linux") OR APPLE)
target_link_libraries(my_python_module ${Boost_LIBRARIES})
elseif(WIN32 AND MSVC)
add_definitions(/DBOOST_PYTHON_STATIC_LIB)
target_link_libraries(my_python_module ${Boost_LIBRARIES}) #This includes the Boost Python library
# Even though Boost Python library is included statically, in Windows it has a dependency to the Python library.
target_link_libraries(my_python_module ${Python_LIBRARIES})
endif()
This works fine in Linux, but in Windows, it only works in Release mode, not in Debug, in which case I always get a:
LINK : fatal error LNK1104: Can't open file 'python37.lib'
After some hair pulling I noticed the issue was caused by CMake instructing Visual Studio to link against 'python37_d.lib' instead of 'python37.lib' in the Debug mode.
However, as I described in the linked issue, the officially provided Boost Python debug library is linked against the Python release library, not the debug one. So, the solution would be to force the link against the Python release library, regardless of the build type. Unfortunately, ${Python_LIBRARIES} sets the library automatically depending on the mode, and I wouldn't like to explicitly specify python37.lib in my code (since I can upgrade Python and I don't want to have to change my CMake scripts because of that).
I found some similar issues here and here, but that doesn't reflect the exact situation I'm facing. Based on those, I tried setting:
target_link_libraries(my_python_module optimized ${Python_LIBRARIES})
But that didn't work either. So, the question is:
Is there a way to force the usage of the Python release library in Debug mode WITHOUT having to set it explicitly and leaving the Python CMake package to do it automatically instead. By explicit I mean doing:
target_link_libraries(my_python_module python37)
Thanks a lot for your help.
It seems that set(Python_FIND_ABI "OFF" "ANY" "ANY") as suggested in the comments by kanstar would be the correct way to do this. However, while Python_FIND_ABI is in CMake master, it hasn't been released yet in the latest version (v3.15.2 as of this writing).
In the meantime, there are solutions dependent on the CMake version.
CMake 3.12 and above
It's possible to link against FindPython's Python_LIBRARY_RELEASE, which isn't meant to be part of the module's public interface, but the variable is set correctly nonetheless.
cmake_minimum_required (VERSION 3.12)
find_package(Python ..<choose your COMPONENTS; refer to FindPython docs>..)
if(WIN32 AND MSVC)
target_link_libraries(my_python_module ${Python_LIBRARY_RELEASE})
endif()
CMake 3.0.4 to 3.11
Thanks to a comment by #Phil, we can expand the answer to include earlier CMake versions which had the FindPythonLibs module that sets the PYTHON_LIBRARY_RELEASE variable instead.
cmake_minimum_required (VERSION 3.0)
find_package(PythonLibs ..<refer to FindPythonLibs docs>..)
if(WIN32 AND MSVC)
target_link_libraries(my_python_module ${PYTHON_LIBRARY_RELEASE})
endif()
I compiled the development version of Vim with both Python 2 and Python 3 support. The output of vim --version has +python/dyn and +python3/dyn in it. I ran the configure file with
g
./configure --enable-pythoninterp --enable-python3interp --with-python-config-dir=/usr/lib64/python2.7/config --with-python3-config-dir=/usr/lib64/python3.3/config --with-x --with-features=huge
However when I run :python import sys; print(sys.version) I get
E448: Could not load library function _PyArg_Parse_SizeT
E263: Sorry, this command is disabled, the Python library could not be loaded.
Why would this be? I found out because of YouCompleteMe stating that it requires Vim compiled with 2.x support.
Thanks
I had a similar issue on my Debian box. If you're using a Debian-based system, you will not be able to load both Python libraries simultaneously. That's why when you set --enable-python-interp and --enable-python3-interp they always load with the /dyn suffix.
If your vim plugins don't need both versions, you should just pick one of the versions and stick with it. The links below provide more info.
Explained by Debian maintainer
Vim Python Support
P.S. - In case you tried this on Windows as well, loading either Python version will work, so the /dyn isn't an issue there.
I have Python 2.7 and Python 3.3 in my Debian. I rebuilt both using the arg --enable-shared.
After than I built VIM 7.4 using the args " --enable-pythoninterp --enable-python3interp --with-features=huge --with-python-config-dir=PathToConfig --with-python3-config-dir=PathToConfig"
when i give the comment vim --version, I could see the flags '+python/dyn and +python3/dyn'
However when I type the command ':python import sys', I get the error message:
E448: Could not load library function _PyArg_Parse_SizeT
E263: Sorry, this command is disabled, the Python library could not be loaded.
When I type the command ':python3 import sys', I get the error message:
E448: Could not load library function PySys_SetArgv
E263: Sorry, this command is disabled, the Python library could not be loaded.
all the vim plugins that needs python is not working due to this.
Please let me know how to fix this.
"Dynamic" Python loading is only available for use on Windows, unfortunately. I have looked into this as well, and it is not available on any other operating system.
The Vim docs: http://vimdoc.sourceforge.net/htmldoc/if_pyth.html#python-dynamic specify: "On MS-Windows the Python library can be loaded dynamically."
Basically the answer is: Nope, "dynamic" will not work on any Mac/*nix systems.
What I've done on my own system is to compile two versions of vim, one with Python2 and the other with Python3 links. Then in my .vimrc I include a version-check to use the right python exec for plugins, etc.
Having some problems with Gdal installation with python 2.7 on Windows 7 32bit. I am running MSVC 2010. I have followed the instruction from the blog website
http://cartometric.com/blog/2011/10/17/install-gdal-on-windows/
The installation is fine. At the end of it, I am able to run ogr2ogr in the MS-DOS and have gotten the similar screen as listed in the blog.
However, when I am trying to use the command "import osgeo" on the Python IDLE GUI shell. A series of error message is released, reading like the following
"DLL error:.........."
I believe that this might mean that the python binding is of wrong version. I have cleared up my installation by removing the following: Python-Gdal binding, Gdal, Python 2.7
After removing them, I have retried my installation with Python 3.2.3 instead and loaded the Gdal package and python binding accordingly. However, the same error returns.
Is there any intermediate steps that I could take to verify the installation. Any other advice I could have to have the bindings installed? Or is my reinstallation method correct?
I have tried to install FWTools too. It doesnt seem to work either. I have run the Python shell from EV-shell and type in "import osgeo". Have gotten the message "no module exist...."
Thanks
Get the precompiled gdal from here:
http://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal
I have some other notes on setting up postgres and postgis 2.0 here if you need it:
http://monkut.webfactional.com/blog/archive/2012/5/2/using-django-14-with-gdal-19-and-postgis-20/