Created attachment 210521 [details] patch Since powerpc64 elfv2 uses LLVM, it can build this port. make test passes ok.
Comment on attachment 210521 [details] patch I'd rather you hook things up like in afl++ for aarch64 and powerpc64, i.e., stop installing useless programs on non-x86 and making LLVM option mandatory. I personally do not see the point though. We already have security/afl++ for powerpc64 and aarch64, afl is stuck on LLVM 8, and afl++ is more active than afl. Why does afl need -mabi=elfv2 but afl++ does not?
(In reply to Tobias Kortkamp from comment #1) I don't have aarch64 to test on, so I'll leave it up to you :) afl needs -mabi=elfv2 because it uses LLVM 8. LLVM 9 has patches that for elfv2 that are autoapplied when building on elfv2, so that it doesn't use elfv1. This is done with: OPTIONS_DEFAULT_powerpc64= ${PPC_ABI:tu:MELFV2} OPENMP ELFV2_EXTRA_PATCHES= ${PATCHDIR}/ppc64-elfv2 at https://svnweb.freebsd.org/ports/head/devel/llvm90/Makefile?view=markup The extra patches are simply https://svnweb.freebsd.org/ports/head/devel/llvm90/files/ppc64-elfv2/patch-lib_Target_PowerPC_PPCTargetMachine.cpp?view=markup and https://svnweb.freebsd.org/ports/head/devel/llvm90/files/ppc64-elfv2/patch-tools_clang_lib_Basic_Targets_PPC.h?view=markup They just set up clang to build for elfv2. It can be done without those patches by passing -mabi=elfv2. LLVM 8 doesn't have those patches but can still build for elfv2 after passing -mabi=elfv2. If afl++ is the superior alternative to this port (with only pros and no cons), then I guess it's fine not to fix it, but then why keep this port in the tree? :)
There is no reason to remove afl and surprise existing users. It can be removed alongside llvm80 when the time comes. There are no existing users of afl on powerpc64 since it is currently not packaged. There is also no reason to spend time to package it correctly on powerpc64 since there is afl++ instead.