Can't compile with Perl v5.22.2

111 views
Skip to first unread message

LCD 47

unread,
May 1, 2016, 2:23:09 PM5/1/16
to vim...@googlegroups.com
This seems to be a recent change in Perl rather than Vim:

clang -c -I. -Iproto -DHAVE_CONFIG_H -pipe -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/include/python3.5m -DPYTHON3_HOME='L"/usr"' -pthread -DDYNAMIC_PYTHON3_DLL=\"libpython3.5m.so.1.0\" -o objects/if_python3.o if_python3.c
In file included from if_perl.xs:610:
/usr/lib/perl5/CORE/inline.h:20:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT_AV_TOP_INDEX'
PERL_ARGS_ASSERT_AV_TOP_INDEX;
^
/usr/lib/perl5/CORE/inline.h:242:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT_APPEND_UTF8_FROM_NATIVE_BYTE'
PERL_ARGS_ASSERT_APPEND_UTF8_FROM_NATIVE_BYTE;
^
/usr/lib/perl5/CORE/inline.h:274:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT__IS_UTF8_CHAR_SLOW'
PERL_ARGS_ASSERT__IS_UTF8_CHAR_SLOW;
^
/usr/lib/perl5/CORE/inline.h:305:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT_IS_SAFE_SYSCALL'
PERL_ARGS_ASSERT_IS_SAFE_SYSCALL;
^
/usr/lib/perl5/CORE/inline.h:390:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT_SV_ONLY_TAINT_GMAGIC'
PERL_ARGS_ASSERT_SV_ONLY_TAINT_GMAGIC;
^

$ perl --version | head -2

This is perl 5, version 22, subversion 2 (v5.22.2) built for i586-linux-thread-multi

/lcd

Damien

unread,
May 1, 2016, 7:55:40 PM5/1/16
to vim...@googlegroups.com
Hi LCD and list,

Please check this patch https://framagit.org/Damien43/patches/raw/master/vim/perl-5.22.2.patch

Thanks.
Damien

Ken Takata

unread,
May 1, 2016, 11:04:12 PM5/1/16
to vim_dev, dami...@gmx.fr
Hi Damien,
I haven't try your patch, because ActivePerl/StrawberryPerl 5.22.2 is not
released yet. BTW, personally I don't like this part:

> @@ -777,7 +784,7 @@ newWINrv(SV *rv, win_T *ptr)
> sv_setiv(ptr->w_perl_private, PTR2IV(ptr));
> }
> else
> - SvREFCNT_inc(ptr->w_perl_private);
> + SvREFCNT((SV *)ptr->w_perl_private)++;
> SvRV(rv) = ptr->w_perl_private;
> SvROK_on(rv);
> return sv_bless(rv, gv_stashpv("VIWIN", TRUE));

Isn't it better to (re)defining SvREFCNT_inc instead of using SvREFCNT()++?

Regards,
Ken Takata

LCD 47

unread,
May 2, 2016, 1:43:23 AM5/2/16
to vim...@googlegroups.com, Damien
Thank you. It does solve the compilation problem, and it also
passes some quick tests.

/lcd

Damien

unread,
May 2, 2016, 2:49:28 AM5/2/16
to vim...@googlegroups.com
Hi Ken,

Thank for your advice.

I changed for SvREFCNT_inc_void_NN(). It do not need of inline.h
and are part of public API.


Regards,
Damien

Bram Moolenaar

unread,
May 2, 2016, 4:22:42 PM5/2/16
to Damien, vim...@googlegroups.com
Is this patch now OK to include? I wonder if it now breaks on other
versions of Perl.

--
Beer & pretzels can't be served at the same time in any bar or restaurant.
[real standing law in North Dakota, United States of America]

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Damien

unread,
May 3, 2016, 8:39:29 AM5/3/16
to vim...@googlegroups.com
Le Mon, May 02, 2016 at 10:22:32PM +0200, Bram Moolenaar a écrit :
>
> Is this patch now OK to include? I wonder if it now breaks on other
> versions of Perl.

Hi Bram,

In v5.18 .. now, I find nothing change for S_SvREFCNT_dec() in Perl
repository.
Just some functions was added.

That nice if someone can confirm.
Using several version of Perl in same time isn't easy :-(.

Regards,
Damien

Kazunobu Kuriyama

unread,
May 17, 2016, 9:22:57 AM5/17/16
to vim...@googlegroups.com
2016-05-03 21:38 GMT+09:00 Damien <dami...@gmx.fr>:
That nice if someone can confirm.
Using several version of Perl in same time isn't easy :-(.

Hi Damien,

Your patch is now being discussed in GitHub Issue #790 (https://github.com/vim/vim/issues/790)

Thanks to Rob Hoelz's intensive investigation, we now know the patch works for 5.14, 5.16, 5.18, 5.20, 5.22 and 5.24, but not for 5.12 or earlier.

I'm sending you this note in case you might not know about #790, which was once titled and reported as if it were a GTK+ GUI build issue and not relevant to the issue which has been discussed in this thread so far.

Best regards,
Kazunobu Kuriyama
Reply all
Reply to author
Forward
0 new messages