Subject: | Curses-1.29 not compatible with perl below 5.16.0 |
Date: | Thu, 10 Apr 2014 11:34:33 -0400 |
To: | bug-Curses [...] rt.cpan.org |
From: | "Daniel Macks" <dmacks [...] netspace.org> |
Building Curses-1.29 on OS X 10.8 using apple's perl-5.12.4 gives a library that fails its selftests:
# Failed test 'use Curses;'
# at t/00-load.t line 6.
# Tried to use 'Curses'.
# Error: Can't load '/sw/build.build/curses-pm5124-1.29-1/Curses-1.29/blib/arch/auto/Curses/Curses.bundle' for module Curses: dlopen(/sw/build.build/curses-pm5124-1.29-1/Curses-1.29/blib/arch/auto/Curses/Curses.bundle, 2): Symbol not found: _utf8_to_uvchr_buf
# Referenced from: /sw/build.build/curses-pm5124-1.29-1/Curses-1.29/blib/arch/auto/Curses/Curses.bundle
# Expected in: flat namespace
# in /sw/build.build/curses-pm5124-1.29-1/Curses-1.29/blib/arch/auto/Curses/Curses.bundle at /System/Library/Perl/5.12/darwin-thread-multi-2level/DynaLoader.pm line 204.
# at t/00-load.t line 6.
# Compilation failed in require at t/00-load.t line 6.
looking back in the build process, the only relevant message was:
gcc -c -I/sw/include/ncursesw -I/sw/include -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -I/usr/local/include -Os -DVERSION=\"1.29\" -DXS_VERSION=\"1.29\" "-I/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE" Curses.c
Curses.c:459:11: warning: implicit declaration of function 'utf8_to_uvchr_buf' is invalid in C99 [-Wimplicit-function-declaration]
UV uv = utf8_to_uvchr_buf(s, s + s_len, &len);
^
Not finding a header declaring a function is consistent with runtime failure to resolve that symbol. According to the perldelta manpages on newer perls, that function was added as of perl-5.16.0, a level that apple only started supplying on its new major-version OS 10.9 (last summer). CPAN Testers reports this same situation across multiple platforms:
http://www.cpantesters.org/distro/C/Curses.html
I don't object to dropping support for older perls when necessary (but would definitely prefer to keep at least fairly-recent usable). But Makefile.PL or some other mechanism should have a prereq check for it so we don't get as far as runtime before being alerted to the incompatibility.
dan
--
Daniel Macks
dmacks@netspace.org