Ben Schmidt, on 08/06/12 at 00:28:58 +1000, wrote: > On 5/08/12 7:13 AM, 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 > > Hmm. Strange. I've never had any problem building (Mac)Vim against > Python, and I certainly don't use --disable-darwin. I suspect I've > always been building against a Python from MacPorts, though. > > >If I do --disable-darwin, I get python support just fine. > > Interesting. > > >It should be known that: > >0. This is on both Tiger and Leopard. There's no problem on 10.7 or even > >10.8 > > I guess I'll have to fire up an older machine to see if I can > investigate this further at all. I should be able to do that if I need > to.
I forgot to mention that the problem also occurs on Snow Leopard. So it's not a PPC/Intel issue (my Tiger and Leopard machines are PPC). > >1. My $PYTHONPATH is set to /usr/local/gmnpyth, which is where python 2.7.3 > >lives. > > How did it get there? I put it there---not just the variable, but python itself. Why? Because I wanted python 2.7.x on a Tiger machine and a Leopard machine, both of which come with outdated pythons. Why did I put a new python *there*? Because it's easier for me to obliterate and troubleshoot, rather than futzing around with frameworks and such. (Because I don't understand any of this stuff, I try to plan escape routes in advance and try not to move system stuff). Note that when I build python 2.7.x from source, I *don't* do --enable-framework. I *do* remember to set MACOSX_DEPLOYMENT_TARGET=blah. > >2. Even on Tiger and Leopard, building *MacVim* with the same $PYTHONPATH and > >--enable-pythoninterp works just fine. > > Also interesting. I wonder if there's a patch in MacVim that should be > 'pushed upstream' or moved outside a preprocessor conditional or > something. > > When you attempt to build BramVim, are you doing it using the MacVim > sources, but disabling the GUI, or with sources directly from Bram. Can > you try it both ways and see if there is any difference? BramVim, by definition, is the sources directly from Bram's hg repo. I have never tried building Vim from Björn's git repo with a --disable-gui flag; I will do so now. -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
