On 14/03/10 02:17, Peter Thomas wrote:


On Mar 13, 5:03 pm, Peter Thomas<pthomas...@gmail.com>  wrote:
On Mar 13, 3:59 pm, Tony Mechelynck<antoine.mechely...@gmail.com>
wrote:



On 13/03/10 20:51, Peter Thomas wrote:

On Mar 13, 2:47 am, Tony Mechelynck<antoine.mechely...@gmail.com>
wrote:
On 13/03/10 10:02, Peter Thomas wrote:

I'm trying to build a version of vim with perl support that will run
under the cygwin terminal (ie. *not* the win32 build). The configure/
make/make install sequence runs to completion with no errors, however
when I fire up vim and do a test perl command like ":perl 'my $i=1;'",
vim quits with this message:

     Vim: Caught deadly signal SEGV
     Vim: Finished.
     Segmentation fault

Versions used:
     - latest cygwin as of this post (setup.exe v2.686)
     - vim 7.2 sources (runtime, lang, and extras), applied patches 001
through 394
     - Perl 5.10.1-3 (the one that comes with cygwin)

Steps followed:
     - open a cygwin terminal...
     - download, unzip and patch vim sources from vim.org
     - cd vim72/src
     - run './configure --enable-perlinterp --prefix=/opt/vimtest'    (to
avoid interfering with cygwin's pre-existing vim)
     - run 'make&&      make install'
     - run '/opt/vimtest/bin/vim.exe'
     - try a ":perl" command ->      observed segfault

Is there something I've overlooked? Can someone please point me in the
right direction, either to fix or to troubleshoot?

Thanks very much,
Peter

Running configure separately is dangerous if the "requirements" of the
Makefile have been modified, because in that case "make" will rebuild
the Makefile, running configure in the process (without your handcrafted
command-line arguments).

I recommend to set configure arguments via environment variables passed
to make, seehttp://users.skynet.be/antoine.mechelynck/vim/compunix.htm
for an example.

I'm not saying that this is necessarily your problem, but it could be,
since you applied quite a number of patches and some of them modify one
or more of Makefile, auto/configure, config.mk etc.

Also, if configure has a problem, it will return a nonzero exit code,
and in that case (if configure was invoked by make) the "compile" step
will not be launched. The config log should tell you what went wrong (I
recommend logging the console messages from configure and make via tee,
but a more detailed config.log is put in the src/auto directory; I
usually don't need that much detail to know what went wrong.

To reconfigure and recompile, use either

          make reconfig

(one step) or

          make config
          make

(two steps), in both cases after setting the proper environment variables.

Best regards,
Tony.
--
FIRST HEAD: All right! All right! We'll kill him first and then have tea and
               biscuits.
                    "Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD

Thanks for your quick reply, Tony.

I've followed your instructions on the above HowTo page, but
unfortunately the segfault problem persists. As a "control"
experiment, I also tried the procedure below replacing
'CONF_OPT_PERL=--enable-perlinterp' with 'CONF_OPT_PYTHON=--enable-
pythoninterp' - the resulting vim.exe handles ":python 'foo=123'"
flawlessly. The trouble seems to be Perl-specific.

Here's a breakdown of the steps I followed (from the HowTo):

    # starting with a fresh source dir described at the top of the
thread (runtime/lang/extras + patches 001-394 applied)
    cd vim 72/src

    export  CONF_OPT_PERL=--enable-perlinterp
    export  CONF_OPT_FEAT=--with-features=huge
    export  CONF_OPT_COMPBY="--with-compiledby=pthomas...@gmail.com"
    export  CONF_OPT_MULTIBYTE=--enable-multibyte
    # I left the remaining CONF_OPT env variables unset for simplicity
(no ruby, tk, etc)

    make config 2>&1 | tee config.log     # ran ok  ($? was 0)
    make 2>&1 | tee make.log    # also ran ok

But running the resulting vim.exe with command ":perl 'my $foo=123;'"
still causes the same segfault, unfortunately.

Is there anything else I could try?

Best regards,
Peter

Hm... Which perl interpreter are you using? For a Vim "for Cygwin",
_both_ the Perl interpreter used to convert src/if_perl.xs to
src/auto/if_perl.c (before compiling src/auto.if_perl.c to
src/objects/if_perl.o or similar) _and_ the one used to interpret Perl
commands issued from Vim must be the same version of Perl, which in this
case must be IIUC _not_ a Perl "for Windows" but a Perl "for Cygwin" --
but I'm not sure that I did UC.

You definitely did UC: my goal is to build a vim+perl to use under
Cygwin Bash (I know that the Cygwin installer lets you install a
precompiled vim, but that version lacks Perl support).



So: What is the reply to "which perl" at the Cygwin bash prompt? Does it
look like a path to a "Cygwin" program or to a "Windows" program? Are

It's Cygwin Perl that is used (which is what we want, I believe):

     $ which perl
     /usr/bin/perl

     $ /usr/bin/perl -v
     This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
     (with 12 registered patches, see perl -V for more detail)

you running Vim-for-Cygwin from Cygwin bash (recommended), from a
Windows Dos Box, from a desktop icon, or in some other way...?

Yes, I'm doing all this through Cygwin bash (ie. opened from the black-
and-green "Cygwin" icon on my Windows desktop)



Best regards,
Tony.
--
Excellent time to become a missing person.

Some additional info...

After recompiling with "CFLAGS=-ggdb" and doing a gdb backtrace right
after the segfault, I get this:

   Thread 1 (thread 3788.0xcf8):
   #0  0x54a586d0 in Perl_sys_init () from /usr/bin/cygperl5_10.dll
   #1  0x0055e4bf in perl_init () at if_perl.xs:477
   #2  0x0055ebe0 in ex_perl (eap=0xfbc620) at if_perl.xs:718
   #3  0x004529a5 in do_one_cmd (cmdlinep=0xfbc7e4, sourcing=0,
cstack=0xfbc7ec,
       fgetline=0x4651fb<getexline>, cookie=0x0) at ex_docmd.c:2629
   #4  0x004502bd in _fu170____stack_chk_guard () at ex_docmd.c:1098
   #5  0x004cd786 in nv_colon (cap=0xfbcb68) at normal.c:5224
   #6  0x004c794b in normal_cmd (oap=0xfbcc10, toplevel=1) at normal.c:
1188
   #7  0x0048e912 in main_loop (cmdwin=0, noexmode=0) at main.c:1211
   #8  0x0048e4cb in _fu230____stack_chk_guard () at main.c:955

Could this be a sign that the problem lies with cygwin perl rather
than vim?


Hm, hard for me to tell. The problem seems to be Perl-related, since the stack shows a fairly straightforward calling sequence of main.c => normal.c => ex_docmd.c => if_perl.xs => cygperl5_10.dll => crash. Now is it a bug in the Perl code, or could a bug in Vim (in if_perl.xs?) have corrupted something that Perl needed, I don't know; but maybe someone else can reproduce the crash on Cygwin, and, who knows? pinpoint the error... I can't.


Best regards,
Tony.
--
"What are we going to do?"

"Me, I'm examining the major Western religions.  I'm looking for
something that's soft on morality, generous with holidays, and has a
short initiation period."

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

Raspunde prin e-mail lui