björn, on 08/05/12 at 18:45:47 +0200, wrote: > On Sat, Aug 4, 2012 at 11:13 PM, gmn wrote: > > I'm sending this here rather than to vim_use because it's a Mac-specific > > problem, even though it's about the official console vim from Bram's hg repo > > (aka "BramVim"). > > > > A short while ago, I discovered I had been calling --disable-darwin for the > > configuring of BramVim. I'd been doing this for years, disguised 'neath a > > bash alias. I couldn't recall why I was doing something so apparently dumb. > > > > Well, I discovered why, I think. > > > > If I don't --disable-darwin, then building vim chokes on enabling the python > > interpreter: > > > > objects/if_python.o objects/os_macosx.o objects/os_mac_conv.o > > objects/main.o objects/memfile.o -lm -lncurses -liconv -lintl > > -framework Cocoa -framework Python > > Undefined symbols: > > "__PyObject_NextNotImplemented", referenced from: > > __PyObject_NextNotImplemented$non_lazy_ptr in if_python.o > > "_PyCapsule_GetPointer", referenced from: > > _convert_dl in if_python.o > > "_PyCapsule_New", referenced from: > > _convert_dl in if_python.o > > ld: symbol(s) not found > > collect2: ld returned 1 exit status > > make[1]: *** [vim] Error 1 > > make: *** [first] Error 2 > > > > 1. My $PYTHONPATH is set to /usr/local/gmnpyth, which is where python 2.7.3 > > lives. > > I'm guessing that there is a version mismatch between the headers that > you build against and the library that is being linked with. In the > output you see "-framework Python" which means it will link against > the system Python (/System/Library/Frameworks/Python.framework). You > can look inside src/auto/config.mk to see which headers are being used > (probably your custom version). > > To get it to work you have to make it build and link the same Python > version. You can do this either by patching src/configure.in (which I > find to be a PITA but would be the right thing to do) or as a > temporary hack by editing src/auto/config.mk (easier). The latter > gets overwritten each time you run configure however...
Though I started this thread as a question about BramVim, it now appears to me that the mystery is really about MacVim. Allow me to explain. Examining src/configure.in for BramVim reveals that the python libs get set starting at line 898, where they get made into "-framework Python" if $MACOSX is set, and some other gibberish otherwise. $MACOSX is governed by --enable/--disable-darwin. So when I --disable-darwin, the "gibberish" in fact sets the python libs, correctly, to my /usr/local/gmnpyth. When I enable darwin, it gets what Björn said above and chokes. End of mystery re BramVim. (I bet the reason my problem only appeared on 10.6 and under is that 10.8 and probly 10.7 have their system python's as 2.7.x anyway, avoiding the choke). Now, mystery re MacVim: the src/configure.in for MacVim has the corresponding line at 921. And $MACOSX is set in MacVim. So the python libs get set to "-framework Python" just like in BramVim with darwin enabled. So then why does MacVim not choke? (And why does it choke when gui is explicitly disabled?). MacVim's src/auto/config.mk seems identical to that of BramVim-with-darwin-enabled on python-related aspects (though not on everything). I notice that in fact MacVim, though it doesn't choke, is not picking up my custom python and instead uses the sytem's old one. That now makes sense. The further mystery is how I can get MacVim (and darwin-enabled BramVim) to pick up my custom python location. (Setting --with-python-config-dir doesn't help). -gmn -- You received this message from the "vim_mac" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
