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