New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExtUtils-MakeMaker in perl 5.28 armv5te fails #16828
Comments
From rob@allenonline.me.ukCreated by rob@allenonline.me.ukAny 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 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 A number of us have hit this problem: https://archlinuxarm.org/forum/viewtopic.php?f=57&t=13134 Perl Info
|
From @jkeenanOn Mon, 28 Jan 2019 12:52:14 GMT, rob@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 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. A number of us have hit this problem: |
The RT System itself - Status changed from 'new' to 'open' |
@jkeenan - Status changed from 'open' to 'new' |
From @LeontOn Mon, Jan 28, 2019 at 6:07 PM James E Keenan via RT
Can you apply the patch at Leon |
The RT System itself - Status changed from 'new' to 'open' |
From robertallen2.uk@googlemail.comHi Leon, I'm really out of my depth now because I don't know how to do patches. This https://metacpan.org/pod/distribution/PerlPowerTools/bin/patch says it should just be:**patch <patchfile but I can't work out which lines of that link you sent are actually the patch file. Rob On 28/01/2019 22:40, Leon Timmermans via RT wrote:
|
From robertallen2.uk@googlemail.comOn 28/01/2019 22:40, Leon Timmermans via RT wrote:
Hi Leon, I've applied the patch to perl perl-5.28.1 run configure: ./Configure -des -Dprefix=/opt/perl-5.28.1-LMS -Dusethreads run make and it still fails: Can't locate ExtUtils/MakeMaker/version/vpp.pm in @INC (you may need to install the ExtUtils::MakeMaker::version::vpp module) BEGIN failed--compilation aborted at /media/usb/repository/software/logitechmediaserver/perl-5.28.1/perl-5.28.1/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 10. Rob |
From @tonycozOn Mon, 28 Jan 2019 04:52:14 -0800, rob@allenonline.me.uk wrote:
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 |
From aaro.koskinen@iki.fiOn Tue, 05 Feb 2019 20:18:43 -0800, tonyc wrote:
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 |
From aaro.koskinen@iki.fiOn Tue, 25 Jun 2019 15:27:08 -0700, aaro.koskinen@iki.fi wrote:
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... The issue is seen on other platforms as well, e.g. SPARC (see #133495) and PA-RISC, where miniperl fails with SIGBUS. |
From rob@allenonline.me.ukOn 30/06/2019 23:27, Aaro Koskinen via RT wrote:
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. |
From @tonycozOn Sun, 30 Jun 2019 15:27:55 -0700, aaro.koskinen@iki.fi wrote:
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. |
From alland@drassal.netI can confirm this also. I am working with Gentoo Linux on a GlobalScale DreamPlug. On Gentoo this is a little more of a hassle since it uses the portage package manager, the configure options are a little more difficult to get at. I temporarily edited the ebuild file and added the -Dd_u32align to the configure command, however, it would be good if this is fixed upstream. In the ebuild, I can see an exception already made for some things such as the below... in the /usr/portage/dev-lang/perl/perl-5.30.0.ebuild file, line 474. For the temporary fix I added " -Dd_u32align \" in /usr/portage/dev-lang/perl/perl-5.30.0.ebuild at line 513 so it was added to the configure options. It would be nice if there was more of a permanent fix made upstream for Gentoo users. Thank you for those who came up with the above temporary solution! I was almost tearing my hair out trying to figure this out! |
From alland@drassal.netI am appending the output of emerge --info Portage 2.3.69 (python 2.7.15-final-0, default/linux/arm/17.0, gcc-8.3.0, glibc-2.29-r2, 3.2.5-dreamplug armv5tel)System uname: Linux-3.2.5-dreamplug-armv5tel-with-gentoo-2.6 gentoo x-portage ACCEPT_KEYWORDS="arm" |
From [Unknown Contact. See original ticket]I am appending the output of emerge --info Portage 2.3.69 (python 2.7.15-final-0, default/linux/arm/17.0, gcc-8.3.0, glibc-2.29-r2, 3.2.5-dreamplug armv5tel)System uname: Linux-3.2.5-dreamplug-armv5tel-with-gentoo-2.6 gentoo x-portage ACCEPT_KEYWORDS="arm" |
From mattst88@gmail.comI suspect my fix attached in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133495 fixes this as well. |
From mattst88@gmail.comOn Sat, 07 Sep 2019 13:12:16 -0700, mattst88@gmail.com wrote:
Those commits are now in as https://perl5.git.perl.org/perl.git/commit/ee9ac1cd8eb988fea70841eae211b11355711416 and should be in the 5.32 release. This is presumably fixed now. |
From @tonycozOn Tue, 08 Oct 2019 13:22:44 -0700, mattst88@gmail.com wrote:
That seems likely, could someone who's seeing this problem test this please? Thanks |
As its been indicated that this detection has been fixed upstream in perl since 5.31.5, and the workaround should no longer be needed Bug: https://bugs.gentoo.org/676062 Bug: https://bugs.gentoo.org/688432 Bug: Perl/perl5#16828 Bug: Perl/perl5#16680 Commit: Perl/perl5@ee9ac1c Commit: Perl/perl5@e8864db Package-Manager: Portage-2.3.103, Repoman-2.3.22 Signed-off-by: Kent Fredric <kentnl@gentoo.org>
Migrated from rt.perl.org#133803 (status was 'open')
Searchable as RT133803$
The text was updated successfully, but these errors were encountered: