Em sexta-feira, 27 de março de 2015 01:51:05 UTC-3, Francisco Lopes escreveu: > Em sexta-feira, 27 de março de 2015 01:44:37 UTC-3, Francisco Lopes escreveu: > > Em quinta-feira, 26 de março de 2015 00:10:51 UTC-3, Kazunobu Kuriyama > > escreveu: > > > On Mar 26, 2015, at 1:36, Francisco Lopes > > > <[email protected]> wrote: > > > > > > > Em segunda-feira, 23 de março de 2015 04:19:30 UTC-3, Kazunobu Kuriyama > > > > escreveu: > > > >> 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 > > > > > > > > Did you review information from issue 315: > > > > https://code.google.com/p/vim/issues/detail?id=315. > > > > > > > > I think it's quite important for solving OS X build problems, I use > > > > that information for flipping a flag and vanish with the linker issues. > > > > > > Hi, > > > > > > If I understand correctly, you mean you fixed the linker issues using the > > > information that was given in the URL you mentioned, right? > > > > > > If so, I’d be happy if you could help me understand what I’m probably > > > missing there. > > > > > > In the URL in question: > > > > > > Comment #1 says “It looks like the fix is not working anymore.” > > > > > > Comment #2 saya “…(with the build patches I mention included).” > > > > > > I’m no sure what “the fix” and “the build patches” are referred to, > > > because I can’t see any of them nor links on the same page. If you know > > > something about them, please let me know. > > > > > > Or, more preferably, why don’t you share with the list the way you > > > actually used to fix the issues? > > > > > > If I come to know something about them, there may be something I can do > > > for Issue 315. > > > > > > Regards, > > > Kazunobu Kuriyama > > > > The way I solve it when I have to build on OS X is just flip the test > > from < 2.3 to >= 2.3. > > > > The reason is explained at the issue, section entitled as "Please provide > > any > > additional information below." > > > > Regards > > Notice, I'm not using -with-python-config-dir anymore. With the flipping patch > the build correctly pics the right python that I've configured for the system > at build time. If I didn't flip, it always picks the system one, it's because > the versions test in the build scripts is actually broken (as explained at the > issue).
So, this solution is not affecting what behavior the build should take regarding -with-python-config-dir. It may be broken or not in an unrelated way, to be solved (or not) in an unrelated form than this. -- -- 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.
