-
Notifications
You must be signed in to change notification settings - Fork 29
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
5.35.6 Cross compile issue, byteorder #125
Comments
Can you check config.log and config.sh? Specifically the values for byteorder, ivsize and ivtype. I'm looking through the code that generates Config_heavy.pm and that '?'x makes me think ivsize is not being set. |
From config.log:
|
Here are my config settings:
I also tried adding |
There should be two relevant sections in config.log, one for the host and another one for the target. The quoted snippets are the host part, the target should have aarch64-linux-musl-gcc instead of cc, and it's going to be further down in the log. It is the target values from config.sh that go into Config_heavy.pl. The host values go into xconfig.sh and only affect miniperl.
|
In this case there is no gcc present on the system. The same clang binary is used for both the host and the target. Here are the values for the target from config.log:
From config.sh:
|
So the values are correct. Then it's down to debugging miniperl configpm, trying to figure out why it's not generating Config_heavy.pl properly from valid inputs. miniperl may be either misconfigured or miscompiled. Side note, I have no idea whether clang works for perl. GCC needs -fwrapv -fno-strict-aliasing to produce usable code. |
So I am also experiencing this issue with aarch64-musl, cross-compiling with GCC. From the OP's comments I tried 5.32.1 and that version is working for me.
|
Noted. That particular function has been re-written between 5.32 and 5.36, however, the re-write was much closer to 5.36 than to 5.32, so that does not align with the failures. Version 5.37 builds just fine on aarch64-glibc, no issues, which makes me think the failures might have something to do with musl. I don't have a musl build environment to test it right away, but at least aarch64 is something I can work with. Maybe I'll try to get a musl system running and investigate it a bit further. |
I had just tried out 5.32 because of the OP's comment. I've now cross-compiled 5.35.9 and that seems to be working for me, so the breakage I'm experiencing seems to have happened between 5.35.9 and 5.36.0. Maybe my issue is a different one than the OP's. |
Well I tried building 5.36.0 in a musl system. No issues, miniperl works, perl works. The system is OpenWRT 21.02.3 running on RPi3, native gcc 8.4.0, target aarch64-openwrt-linux-musl. No idea what's going on. The new version of toke.c was introduced in 5.35.10. The old one did not use Might be worth poking around with gdb when it segfaults, just to get a better idea of what exactly goes wrong. Like what's the value of |
I am seeing the same issue as the OP when cross-compiling 5.36.0 or 5.34.1 from x86_64 to riscv64 with gcc. 5.32.1 works fine. |
Bisected the first failure to Perl/perl5@2e8a5b7.
Or in some revisions after Perl/perl5@b33c3c1 the error is slightly different
Then, in Perl/perl5@bb38256 and later, the OP's error appears:
|
Changes in commit Perl/perl5@63da814 also seem to break something. Weird that there are so many different breakages within a short time frame. |
@arsv |
This happens for me on 5.35.6, but I can't get most previous version to cross build either. The most recent version I can cross build successfully is 5.32.1.
Error:
Build system: powerpc64le-linux-musl
Target system: aarch64-linux-musl
...but this happens when targetting other architectures also. Doing a native build is fine.
lib/Config_heavy.pl line 1468 is:
I have tried setting
-Dbyteorder=12345678
in my config, it makes no difference if present or not.One difference on my system is that it is using clang as the compiler, and no gcc or binutils are present. Not sure if this will affect things?
The text was updated successfully, but these errors were encountered: