Package extra/john
illegal hardware instruction with -O3
#249
Labels
No Label
blocked upstream
bug
build-failure
duplicate
enhancement
help wanted
informational
invalid
invalid/corrupt package
packaging issue
priority: high
question
support
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ALHP/ALHP.GO#249
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When compiling with -O3, the generated code contained XOP instructions, which didn't belong to x86-64-v3 micro-architecture level. However it was compiled and ran without any problem with -O2
If I interpret the PKGBUILD for
john
correctly, that is somewhat intended.Did you have a look in
/usr/lib/john/
? There should be a john binary in there without XOP, namedjohn-non-xop
.You are right. The the reason why john with xop was the default binary is they want the program to fall back from the most feature to less feature instruction sets. However, in the default build script in the john repo, they pass the simd instruction to the configure script, not the compiler (CFLAGS). I guess this caused the problem, but I need to look into this further.
Btw as you can see, the default Archlinux's PKGBUILD doesn't include optimizations for avx2 and avx512f, so compiling it with march doesn't make any big differences. We need to change the PKGBUILD to include optimization for v3 and v4, and possibly delete cpu fallback altogether since we only target 1 micro architecture per build to reduce the size of the package as well. I can try to take a look and help but in worst case scenario, we can blacklist this package because of the above reason.
Obviously that breaks with ALHP. (besides that, the
build.sh
is not used in the Arch build)It doesn't need to include these flags, they are enabled by
march
(and further optimization based on these flags by-O3
. That's why you only had the SIGILL on-O3
). What Arch is doing in their PKGBUILD is only because there is no v2/v3/v4 on official Arch, so they had to rely on that logic. If you check the git history of that file, that part was actually written 5-7 years ago.I agree that the default binary linked to
usr/bin
crashing is suboptimal, but we could add a FAQ entry forjohn
.Sorry my bad. You are completely right. I tried to compile the git repo and couldn't reproduce the problem. The release was from 2019 so they might have fixed it by now. Thank you for your support.
Closing this as solved.