On Wed, Oct 21, 2015 at 11:33:44PM +0100, Zefram wrote:
> The compiler-dependent problem turned out to be some C-level undefined
> behaviour in the module, with insufficient sequence points around a
> variable mutation. The compilers differed in whether they performed
> the write before or after a
The compiler-dependent problem turned out to be some C-level undefined
behaviour in the module, with insufficient sequence points around a
variable mutation. The compilers differed in whether they performed
the write before or after a call to a Perl core function (yylex())
that in 5.22 has come to
Niko Tyni wrote:
>However, building Data-Alias-1.19 with clang works even on our packaged
>perl 5.22.0-4. So the perl build doesn't seem to matter that much.
Thanks, that's a very useful set of results. Compiler used to build
D-A matters. It must be doing something hacky at the C language level
On Wed, Oct 21, 2015 at 06:22:28PM +0100, Zefram wrote:
> It would be really helpful if someone with a failing setup would
> try figuring out which part of the perl build makes the difference.
> Something I haven't yet tried varying is the C compiler. I'm using Debian
> gcc 4.7.2-5, which doesn't
Hi, I'm the Data-Alias maintainer. Data-Alias has been updated for Perl
5.22, in Data-Alias-1.19, now on CPAN. However, I've had reports from two
separate users describing test failures of D-A-1.19 on vendor versions
of Perl 5.22, one Debian and one Fedora. These new test failures are
recognisab
Source: libdata-alias-perl
Version: 1.18-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.22-transition
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=100944
This package FTBFS with perl 5.22:
x86_64-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrap
6 matches
Mail list logo
