[vim-7.1.293+python] wrong Python linked?

[frodwith@…]

With python25 installed and "python_select"ed, I get this error when running my first :python command in a new vim session.

sys:1: RuntimeWarning: Python C API version mismatch for module vim: This Python

has API version 1012, module vim has version 1013.

As nearly as I can tell, vim is getting built with -framework Python instead of the stuff python-config would give you (-ldl -lpython2.5). I don't know if this is a bug for the port to fix or for vim to fix, please advise. :)

[skymoo (Adam Mercer)]

assign to maintainer

[raimue (Rainer Müller)]

Ok, I see a real problem here. The build system of vim always builds against the first 'python' binary it finds in PATH. This means it takes the includes and libs of this binary.

If you still have it, could you please provide the output of:

otool -L /opt/local/bin/vim

(Sorry at this point for examining this bug so late, I was busy.)

Currently I see no solution how we could fix this bug without rewriting the vim configure checks. And I also think the same applies to ruby and perl when linked into vim.

[frodwith@…]

hephaestus:pdriver $ otool -L /opt/local/bin/vim
/opt/local/bin/vim:
        /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)
        /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.5)
        /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl (compatibility version 8.4.0, current version 8.4.0)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 368.33.0)
        /usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.2)
        /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)

[raimue (Rainer Müller)]

I think the problem here was that at build time python from the system was used and later python25 was installed and made the default. But now the python in PATH changed and causes this error message.

To avoid a similar issue in #13292, I made python25 a mandatory dependency for the +python variant. I hope this also fixed this issue here.

I am closing this ticket, please reopen if the issue remains.

[frodwith@…]

port uninstall vim port clean vim port sync port upgrade outdated port install vim +python

issue still persists. the macports python25 has always been the first one in my path, so I didn't anticipate that this would work. One workaround might be to try ripping the shipped Apple python out, but I fear this might break things that depend on it. The problem seems to be somewhere in vim's build process - for instance, the vim module is getting built with the proper python, but vim the editor is getting linked to the Apple version.

[raimue (Rainer Müller)]

Hm, okay. Seems like I will have to dive deeper into vim's build system.

[mf2k (Frank Schima)]

Does it work if you first run the following?

sudo port install python_select

[frodwith@…]

no; python25 has always been python_select'd.

[raimue (Rainer Müller)]

I was trying to solve this issue using the --with-python-config-dir=${prefix}/lib/python2.5/config switch, but it is not so easy. First, I had to comment out the hardcoded string "-framework Python", which is why it is always picking up python from the system.

In ${prefix}/lib/python2.5/config/Makefile the variable LINKFORSHARED is set to "-ldl -u _PyMac_Error Python.framework/Versions/2.5/Python". This cannot work as the path to the framework is missing and therefore linking with these flags fails.

python should be fixed first to give the whole path to the framework directory in LINKFORSHARED and not only a part. Then this will hopefully work for vim.

[blb@…]

Rainer, can you try against python26 if you have a chance, I updated the config/Makefile so LINKFORSHARED is better (in r42841).

[raimue (Rainer Müller)]

With -F ... -framework Python in LINKFORSHARED it is possible to link against the wrong python version, as it always uses Versions/Current which is managed by python_select. Can't we use ${frameworks_dir}/Python.framework/Versions/2.6/Python instead to be more specific and less error-prone?

I was able to build vim against the right python 2.6 now. Can we backport this fix to python 2.5? I don't want to force users to install python26 at the moment, as it is not yet fully supported with modules etc.

[raimue (Rainer Müller)]

files/patch-vim-python.diff

[raimue (Rainer Müller)]

Updated the attached patches to include a new configure option --with-python=PATH which is necessary to get configure to use the right python version.

[blb@…]

I think if the python ports instead use

LINKFORSHARED=  -u _PyMac_Error $(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)

it may work better?

[raimue (Rainer Müller)]

Even with this LINKFORSHARED, it will still pick up python from PATH which does not have to be the matching python install for the framework. Mixing versions of command line client and framework gives problems.

[blb@…]

But it does link against the python you want right? I'm having a similar issue with ajp-wsgi where, if I want to link against 2.6 but have 2.5 selected, it actually links against both frameworks...but when I used the aforementioned LINKFORSHARED, it only links against the right one. So from at least the python ports' point of view, that LINKFORSHARED may be what's needed for proper linking to it.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[aetherknight@…]

Cc Me!

[raimue (Rainer Müller)]

Finally fixed in r49482 by patching vim's configure. Will look into adapting the same for MacVim.

[(none)]

Milestone Port Bugs deleted

[raimue (Rainer Müller)]

I did the same for MacVim in r49492, so this can be closed.