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.
--
--
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.
