Em sexta-feira, 27 de março de 2015 11:16:17 UTC-3, Francisco Lopes escreveu: > Em sexta-feira, 27 de março de 2015 10:52:22 UTC-3, Kazunobu Kuriyama > escreveu: > > On Mar 27, 2015, at 13:53, Francisco Lopes > > <[email protected]> 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 > > >>>> <[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. > > > > 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. > > I'll try it soon, but I assure you, to check that the usage of the > return of the boolean test was broken I've tried it in a minimal case just > to make sure. I'm sure it was this, and I've proved it by: > > - Debugging the problem and finding the probable cause. > - Isolating it and confirm my suspicions. > - Fliping the test, so that it accepts does what should be done for Python > > 2.3. > - It worked, it linked correctly all the times I had to build Vim on OS-X, > even more, I've help someone else suffering from the same problem, and the > solution worked the same in his machine, you may check this here: > > https://github.com/Valloric/YouCompleteMe/issues/1351
It looks like the codebase got fixed. -- -- 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.
