On Mar 27, 2015, at 13:53, Francisco Lopes <francisco.mailing.li...@oblita.com>
wrote:
> 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
>>>> <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.
It looks you are misunderstanding how shell’s IF statements work with exit
codes.
Let ${vi_cv_var_python_version} be 2.7. Since the inequality 2.7 < 2.3 is
false, the command line
/your/path/to/python -c “import sys; exit(${vi_cv_var_python_version} < 2.3)”.
returns 0 as the exit code, which is to be evaluated *true* if it is used as
the condition of a IF statement. Yes, 0 means *true* there. They are not
typos.
So, the condition in the IF statement you’re accusing is, indeed, evaluated
true if the given python’s version is equal to or greater than 2.3, and false
if it is less than 2.3.
Consequently, there’s nothing wrong with the IF statement you're complaining to
In my view, your build happened to go well because the linker flags fell back
to those for other UNIX variants as if the option —disable-darwin were given to
python relevant part of the configure script, and because you were lucky enough
to have your own configure script detect correct linker flags somehow or other.
Obviously, that's not the right thing to do unless —disable-darwin is a user's
choice and/or intent from the outset. In short, it’s wrong.
>>>
>>> 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.
Where is “the flipping patch”? Please stop referring to something we have no
access to any more.
>> 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).
As I explained above, it’s not broken the way you claimed.
It was broken because it failed to pass right framework flags to the linker,
and has been fixed with Patches 7.4.676 and 7.4.677.
> 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.
Anyway, could you try the latest vim source and see if the new configure script
yields Makefiles leading to a successful build? If you’re satisfied with it,
close Issue 315, please. Otherwise, let us know.
--
--
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.
