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
> > <francisco.mailing.li...@oblita.com> 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).
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
