| Hi list, The attached patch was written to address two issues on Vim build on Mac OS X with privately installed Python. (1) The current configure script uses the responses of the Python executable AC_PATH_PROGS() finds. This doesn’t cause any problem when you try to link Vim against the Python that came to your system together with the OS. But when you installed another Python and try to link Vim against it, you’ll find that the resulting Vim is always linked against the Python framework of /usr/bin/python, not that of, e.g., /opt/local/bin/python, even if the configure script correctly detects that the Python executable /opt/local/bin/python differs from the native /usr/bin/python. This issue is caused by forgetting to tell the linker to use an extra linker search path which corresponds to the Python framework you want to use. The proposed patch addresses the issue by prepending an appropriate linker search path if the Python executable in use doesn’t look like the native one so that the linker will try to link vim against your favorite Python first. The path is determined by examining the contents of config/Makefile in the Python framework corresponding to the executable in use. (2) Another issue is closely related to the issue above and they surely resemble one another. But the cause of it slightly differs from that and thus should be handled as such. The current configure script relies on the variables defined in Python framework’s config/Makefile. LINKFORSHARED is one of such variables and has a form of: -u {symbol} {path} When Vim is built on Mac OS X with —disable-darwin, the configure script is to pass the value of LINKFORSHAED to the linker without referring to a Python framework. If {path} is relative, then it is almost certain that you’ll suffer from a “No such file or directory� error from the linker behind the scenes. Consequently, if LINKFORSHARED contains a relative path while the privately installed Python is known usable, then the “sanity� test on compile and linker flags is doomed to fail. In other words, the test gives an unreliable result when {path} is relative. This is what had happened to me with Python (2.7.9) that was privately installed through MacPorts. The proposed patch corrects the behavior of the configure script by checking whether or not the given {path} makes sense for the linker, and, if necessary, make and try other candidates so that the sanity test will give a result more faithful to the state of the system. The issue (1) may be related to Issue #315, but I don’t want to claim that this patch solves #315, because the Mac system mentioned there looks different from mine in subtle points. So I’m not sure if #315 is solved with the patch. Regards, Kazunobu Kuriyama -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. |
configure.in.patch
Description: Binary data
-- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. |
