[perl #133803] ExtUtils-MakeMaker in perl 5.28 armv5te fails

[James E Keenan via RT]

On Mon, 28 Jan 2019 12:52:14 GMT, ***@allenonline.me.uk wrote:
[Reformatting so that content displays better in RT -- jkeenan]

Any attempt to access CPAN on ArchlinuxArm on armv5te processors results in:

"Can't locate ExtUtils/MakeMaker/version/vpp.pm in @INC (you may need to install the
ExtUtils::MakeMaker::version::vpp module) (@INC contains: /usr/lib/perl5/5.28/site_perl
/usr/share/perl5/site_perl /usr/lib/perl5/5.28/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib/perl5/5.28/core_perl /usr/share/perl5/core_perl) at (eval 14) line 1."

Maintainer of ExtUtils::MakeMaker suggested this test 'perl -Mversion -e1' which gives:

"Can't use string ("version::regex::LAX_DOTTED_DECIM"...) as a SCALAR ref while "strict refs" in use at /usr/share/perl5/core_perl/version.pm line 21.
Compilation failed in require.
BEGIN failed--compilation aborted."

A number of us have hit this problem:

https://archlinuxarm.org/forum/viewtopic.php?f=57&t=13134



---
via perlbug: queue: perl5 status: new
https://rt.perl.org/Ticket/Display.html?id=133803

[(via RT)]

# New Ticket Created by
# Please include the string: [perl #133803]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=133803 >

[Tony Cook via RT]

Post by James E Keenan via RT
Maintainer of ExtUtils::MakeMaker suggested this test 'perl -Mversion -e1'
"Can't use string ("version::regex::LAX_DOTTED_DECIM"...) as a SCALAR ref while "strict refs" in
use at /usr/share/perl5/core_perl/version.pm line 21.
Compilation failed in require.
BEGIN failed--compilation aborted."

That checks your system perl, but for a perl build you need to check the bundled modules with the perl you're building.

Inside the perl build directory please run:

./miniperl -Mversion -e0

Please include everything that outputs if it fails.

This uses miniperl, since that's what make_ext.pl will be using. It skips adding -Ilib since lib/buildcustomize.pl should have been built at this point and miniperl will load that.

Tony

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=133803

[Aaro Koskinen via RT]

Post by Tony Cook via RT
./miniperl -Mversion -e0
Please include everything that outputs if it fails.

I have this same issue when trying to build stock 5.28 (or .30) Perl on armv5tel (Linux v5.1, GCC 8.3.0, glibc 2.29).

perl-5.30.0$ ./miniperl -I./cpan/version/lib -I./lib -Mversion -e0
Can't use string ("version::regex::LAX_DOTTED_DECIM"...) as a SCALAR ref while "strict refs" in use at cpan/version/lib/version.pm line 21.
Compilation failed in require.
BEGIN failed--compilation aborted.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=133803

[Aaro Koskinen via RT]

Post by Aaro Koskinen via RT

Post by Tony Cook via RT
./miniperl -Mversion -e0
Please include everything that outputs if it fails.

I have this same issue when trying to build stock 5.28 (or .30) Perl
on armv5tel (Linux v5.1, GCC 8.3.0, glibc 2.29).
perl-5.30.0$ ./miniperl -I./cpan/version/lib -I./lib -Mversion -e0
Can't use string ("version::regex::LAX_DOTTED_DECIM"...) as a SCALAR
ref while "strict refs" in use at cpan/version/lib/version.pm line 21.
Compilation failed in require.
BEGIN failed--compilation aborted.

This issue seems to be caused by wrong alignment causing unexpected behaviour. Running Configure with -Dd_u32align makes the build succeed.

The Configure alignment test produces wrong result for ARMv5t with modern GCC:

Checking to see whether you can access character data unalignedly...
(Testing for character data alignment may crash the test. That's okay.)
You can access character data pretty unalignedly.

The issue is seen on other platforms as well, e.g. SPARC (see #133495) and PA-RISC, where miniperl fails with SIGBUS.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=133803

[Rob Allen]

Post by Aaro Koskinen via RT

Post by Aaro Koskinen via RT

Post by Tony Cook via RT
./miniperl -Mversion -e0
Please include everything that outputs if it fails.

I have this same issue when trying to build stock 5.28 (or .30) Perl
on armv5tel (Linux v5.1, GCC 8.3.0, glibc 2.29).
perl-5.30.0$ ./miniperl -I./cpan/version/lib -I./lib -Mversion -e0
Can't use string ("version::regex::LAX_DOTTED_DECIM"...) as a SCALAR
ref while "strict refs" in use at cpan/version/lib/version.pm line 21.
Compilation failed in require.
BEGIN failed--compilation aborted.

This issue seems to be caused by wrong alignment causing unexpected behaviour. Running Configure with -Dd_u32align makes the build succeed.
Checking to see whether you can access character data unalignedly...
(Testing for character data alignment may crash the test. That's okay.)
You can access character data pretty unalignedly.
The issue is seen on other platforms as well, e.g. SPARC (see #133495) and PA-RISC, where miniperl fails with SIGBUS.

Well done Aaro Koskinen for figuring out this solution. By using it I've successfully run perl-5.30.0 through Configure; make; make test and make install.

[Tony Cook via RT]

Post by Aaro Koskinen via RT

Post by Aaro Koskinen via RT

Post by Tony Cook via RT
./miniperl -Mversion -e0
Please include everything that outputs if it fails.

I have this same issue when trying to build stock 5.28 (or .30) Perl
on armv5tel (Linux v5.1, GCC 8.3.0, glibc 2.29).
perl-5.30.0$ ./miniperl -I./cpan/version/lib -I./lib -Mversion -e0
Can't use string ("version::regex::LAX_DOTTED_DECIM"...) as a SCALAR
ref while "strict refs" in use at cpan/version/lib/version.pm line
21.
Compilation failed in require.
BEGIN failed--compilation aborted.

This issue seems to be caused by wrong alignment causing unexpected
behaviour. Running Configure with -Dd_u32align makes the build
succeed.
The Configure alignment test produces wrong result for ARMv5t with
Checking to see whether you can access character data unalignedly...
(Testing for character data alignment may crash the test. That's
okay.)
You can access character data pretty unalignedly.
The issue is seen on other platforms as well, e.g. SPARC (see #133495)
and PA-RISC, where miniperl fails with SIGBUS.

There's a few problems between the test code in Configure, the assumptions made in hv_macro.h, and in the implementation in gcc.

Firstly the test code in Configure.

ARMv5 is pretty strange[1] when reading from unaligned addresses, instead of throwing an exception or reading the four bytes (for 32-bit reads) starting from the specified address, it reads from the address with the bottom two bits masked off, then uses those two bits as a rotate count (in multiples of 8).

On writes it simply ignores the bottom two bits.

This would mean that the read test code in the probe might get a false success.

The write code should however reject it, assuming the optimiser didn't intervene.

The other major problem is the optimiser acting as if the unaligned access behaved like x86 (ignoring endianess), and optimising out the test, not just on ARM.[2]

We could modify the test to detect the ARMv5 read strangeness, and maybe make the write test more robust, since if writes on ARMv5 behaved like the inverse of reads, we'd have brokenly accepted ARMv5 as allowing unaligned access, even without the intervention of the optimiser.

The other fix to be done here is working around the optimiser, which I suspect will be a race between ours and the compiler writer's ingenuity.

Secondly, the code in hv_macro.h

The probe in Configure only checks for 32-bit unaligned access, but the code in hv_macro.h assumes that this applies also to 64-bit accesses, which might not be the case.

This would need to be fixed by a separate 64-bit probe.

Thirdly, the code generated.

At least in 2010 the code generated for __builtin_bswap() on older ARM was fairly horrible[3], the fallback code might be preferable. Detecting this at Configure or compilation time might be difficult though (maybe nm on a test .o to see if __bswapdi2() is being referenced.)

Tony

[1] https://heyrick.eu/aw/index.php?title=Unaligned_data_access#ARM_v5_and_earlier

[2] Since access to unaligned addresses produces undefined behaviour, gcc is doing nothing wrong here.

[3] https://hardwarebug.org/2010/01/14/beware-the-builtins/

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=133803

[via RT]

I suspect my fix attached in https://rt.perl.org/Ticket/Display.html?id=133495 fixes this as well.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=133803

[Tony Cook via RT]

Post by via RT
I suspect my fix attached in
https://rt.perl.org/Ticket/Display.html?id=133495 fixes this as well.

Those commits are now in as
https://perl5.git.perl.org/perl.git/commit/ee9ac1cd8eb988fea70841eae211b11355711416
https://perl5.git.perl.org/perl.git/commit/e8864dba80952684bf3afe83438d4eee0c3939a9
and should be in the 5.32 release.
This is presumably fixed now.

That seems likely, could someone who's seeing this problem test this please?

Thanks


---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=133803

[via RT]

Post by via RT
I suspect my fix attached in
https://rt.perl.org/Ticket/Display.html?id=133495 fixes this as well.

Those commits are now in as

https://perl5.git.perl.org/perl.git/commit/ee9ac1cd8eb988fea70841eae211b11355711416
https://perl5.git.perl.org/perl.git/commit/e8864dba80952684bf3afe83438d4eee0c3939a9

and should be in the 5.32 release.

This is presumably fixed now.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=133803