vim compiles with wrong python version (and not working with needed version)

Each Answer to this Q is separated by one/two green lines.

In brief:

I have a problem with compiling vim with preferred python version.
When I use --enable-pythoninterp it compiles with system OSX python version.
When I use --enable-pythoninterp=dynamic I get an error in vim while trying :py import sys

Here is what I was doing in more detail:

% git clone
% cd macvim
% ./configure --enable-pythoninterp \
     --with-python-config-dir=/usr/local/lib/python2.7/config <- this option has no affects on result
checking for python... /usr/local/bin/python
checking Python version... 2.7
checking Python is 1.4 or better... yep
checking Python's install prefix... /usr/local
checking Python's execution prefix... /usr/local
checking Python's configuration directory... /usr/local/lib/python2.7/config
% make
% open src/MacVim/build/Release/

In the opened MacVim I type:

:py import sys; print (sys.version, sys.executable)
('2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
  [GCC 4.2.1 (Apple Inc. build 5646)]',

Why 2.6.1?
Why /usr/bin/python?
My default python is 2.7! And it lives at /usr/local/bin/python

I was searching for solution all day. And I found it. It is =dynamic attribute (but this solution had not explanation).

After that I tried to recompile vim with dynamic python:

% ./configure --enable-pythoninterp=dynamic
... output the same ...
% make
% open src/MacVim/build/Release/

In opened MacVim:

:py import sys

And here comes an error:

E370: Could not load library libpython2.7.a
E263: Sorry, this command is disabled, the Python library could not be loaded.

My OSX version is 10.6.8.
Default python version is 2.7.

% which python

Can anybody explain how python is integrating into vim during the compilation?
And how to fix the error with libpython2.7.a?

update: I no longer have the environment described at the question. So I couldn’t test new answers. But remaining part of mankind will appreciate your help.

My solution was to delete the configure cache file which was created from a previous built where I used the python which came with OSX.

Then I installed a new python version with homebrew and couldn’t get .configure to take the new python version, even though I updated my PATH variable and which python showed the right python version.

Deleting the cache file and running configure again solved my problem.

rm src/auto/config.cache
./configure --enable-pythoninterp

Maybe it helps anybody.

I had the same problem. I compiled Macvim from source and tried to use the python version 2.7 from macports in:


Some modules were not found, for example the os module. The reason for this was that the PYTHONPATH variable inside macvim is wrong!

To test, open macvim and type:

:python print sys.path

I got the following paths (note the ending, which is nonsense):


I presume the reason is in the linker flag “-framework Python”. This picks up the wrong, i.e. the system python framework. If I change the line in the src/auto/configure script from:

if test "x$MACOSX" = "xyes" && ${vi_cv_path_python} -c \
"import sys; sys.exit(${vi_cv_var_python_version} < 2.3)"; then
      vi_cv_path_python_plibs="-framework Python"


if test "x$MACOSX" = "xyes" && ${vi_cv_path_python} -c \
"import sys; sys.exit(${vi_cv_var_python_version} < 2.3)"; then
      vi_cv_path_python_plibs="-F/opt/local/Library/Frameworks -framework Python"

Running configure again, after make clean,
Macvim compiles and works as expected. The -F flag tells the linker in which directory to find the following framework. Macports installs the Python.framework in this directory, YMMV.

I had a the same probleme as you (trying to compile MacVim with Python 2.7) and I finally managed to do it.

First the dynamic option doesn’t work ! I’ve seen that tip too on the net, but if you look at the configure script (or just the help) it’s not recognized. Therefore don’t use it. That’s equivalent to disabling python, which explain why :py doesn’t work. You haven’t compiled MacVim with Python.

What I’ve done at the end was reinstall Python 2.7.2 using the official installer on the Python website.
You should then have a config in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config.

Try to compile again with the following options

% ./configure --enable-pythoninterp \

That gave me an error at the end of the compilation, but if I ignore it and launch the binary anyway that works. This problem might be specific to my computer (it seems to be related to the icon instalation).
Good luck.

Note that’s the way I managed to compile MacVim with Python 2.7 (which was my objective) not necessarily the way to compile it with my runtime version of Python.

Make sure that the proper “python” is in your $PATH, which might not be the case when using “sudo”.

There is an option to set the python binary to be used (if you cannot modify $PATH):

export vi_cv_path_python=/usr/local/bin/python

But still, with enable-pythoninterp=dynamic it failed to load libpython2.7.a when running “:python import sys”, saying “E448: Could not load library function _PyArg_Parse_SizeT”.

It sounds like the root of your problem lies in that Python is looking to the wrong directory. That should be the first part you look to correct, before worrying about integrating into vim. All Macs come with a version of Python already installed on their machine, in /usr/local/bin/python. Usually by the time you get the machine, you want install a more recent version of Python. The new version should be located:

% which python

I don’t know how you installed Python to begin with, but the easiest way is easy_install or pip. This is a good link. If that doesn’t solve your path problem, then you should see here. Hopefully this is all you need and the problem with vim will be resolved.

I found the above answer to be dangerous– caused fatal errors when closing buffers in macvim.

The answer found here is much more stable:
Vim failing to compile with python on OS X

I just had the exact same wish, and MacPorts fulfilled it without additional fiddling:

$ port info macvim
MacVim @7.3.snapshot66, Revision 2 (editors)
Variants:             big, cscope, [+]huge, perl, python, python25, python26, python27, python31, python32, python33, ruby, ruby19, tcl, universal, xim

$ sudo port install macvim +python27
--->  Computing dependencies for MacVim
--->  Fetching archive for MacVim
--->  Attempting to fetch MacVim-7.3.snapshot66_2+huge+python27.darwin_10.x86_64.tbz2 from
--->  Attempting to fetch MacVim-7.3.snapshot66_2+huge+python27.darwin_10.x86_64.tbz2 from
--->  Attempting to fetch MacVim-7.3.snapshot66_2+huge+python27.darwin_10.x86_64.tbz2 from
--->  Fetching distfiles for MacVim
--->  Verifying checksum(s) for MacVim
--->  Extracting MacVim
--->  Applying patches to MacVim
--->  Configuring MacVim
--->  Building MacVim
--->  Staging MacVim into destroot
--->  Installing MacVim @7.3.snapshot66_2+huge+python27
--->  Deactivating MacVim @7.3.snapshot66_2+huge
--->  Cleaning MacVim
--->  Activating MacVim @7.3.snapshot66_2+huge+python27
--->  Cleaning MacVim
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  No broken files found.

Note: As you can see above (deactivating), I’ve tried the default (precompiled) MacVim first (ie. sudo port install macvim -> MacVim @7.3.snapshot66_2+huge), and it didn’t have Python support compiled in.

After the adding the +python27 variant, running :py import sys; print (sys.version, sys.executable) inside the newly installed MacVim now returns:

('2.7.3 (default, Oct 22 2012, 06:12:28) \n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]', '/Applications/MacPorts/')

which happens to be the same as I have in my shell (depending on your $PATH and port select python):

$ which python
$ python
Python 2.7.3 (default, Oct 22 2012, 06:12:28)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

The fix I found for this issue involved deleting the source and reacquiring it. I’m sure hg has a way to just delete the local changes, but I couldn’t really find it in the help file.
I didn’t use MacVim, but I suspect your issue is for the same reason.

Looking through the output of the configuration script it appears that it caches the python installation it used previously and just uses that.

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .