Bug#787453: libdata-alias-perl: FTBFS with perl 5.22
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 call to a Perl core function (yylex()) > that in 5.22 has come to depend on the variable more than it used to. > > Fixed in Data-Alias-1.20, now on CPAN. Awesome, many thanks for your work! -- Niko Tyni nt...@debian.org
Bug#787453: libdata-alias-perl: FTBFS with perl 5.22
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 recognisable by a bunch of syntax-related error messages from the test suite, starting with a "Useless use of anonymous hash" warning from t/03_copy.t, following build success. I have not been able to reproduce this new failure myself. It doesn't happen with my usual configurations of stock Perl 5.22. It doesn't happen if I apply as much of the Fedora configuration settings as I can to stock 5.22. It even doesn't happen if I use my usual configuration after applying the patches from the Debian perl 5.22.0-4 package. 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 understand the -fstack-protector-strong option that the failing perls are built with. -zefram
Bug#787453: libdata-alias-perl: FTBFS with perl 5.22
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 of which I was not previously aware. I can probably track it down from here. -zefram
Bug#787453: libdata-alias-perl: FTBFS with perl 5.22
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 understand the -fstack-protector-strong option > that the failing perls are built with. I've just tried building Data-Alias-1.19 on unmodified upstream Perl 5.22.0 with gcc 4.8.5 and 5.2.1, with and without -Dusethreads, and with and without -fstack-protector-strong. It fails with all of these. 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. For more data points, all 5.22.0 CPAN testers seem to fail except Darwin, which is using clang of course. Even Win32 builds fail :) Unfortunately I don't have gcc-4.7 handy right now, so I can't say yet if that works for me or not. Hope this helps a bit, -- Niko Tyni nt...@debian.org
Bug#787453: libdata-alias-perl: FTBFS with perl 5.22
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 depend on the variable more than it used to. Fixed in Data-Alias-1.20, now on CPAN. -zefram
