don't have full logs atm; will post when i do >>> Emerging (11 of 31) app-forensics/afl-1.80b::gentoo * afl-1.80b.tgz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking afl-1.80b.tgz to /var/tmp/portage/app-forensics/afl-1.80b/work >>> Source unpacked in /var/tmp/portage/app-forensics/afl-1.80b/work >>> Preparing source in /var/tmp/portage/app-forensics/afl-1.80b/work/afl-1.80b ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/app-forensics/afl-1.80b/work/afl-1.80b ... >>> Source configured. >>> Compiling source in /var/tmp/portage/app-forensics/afl-1.80b/work/afl-1.80b ... make -j5 -O CC=x86_64-pc-linux-gnu-gcc PREFIX=/usr HELPER_PATH=/usr/lib64/afl DOC_PATH=/usr/share/doc/afl-1.80b ... make -j5 -O PREFIX=/usr HELPER_PATH=/usr/lib64/afl DOC_PATH=/usr/share/doc/afl-1.80b [*] Checking for working 'llvm-config'... [*] Checking for working 'clang'... [*] Checking for '../afl-showmap'... [+] All set and ready to build. clang -O2 -march=amdfam10 -pipe -g -frecord-gcc-switches -Wimplicit-function-declaration -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/lib64/afl\" -DBIN_PATH=\"/usr/bin\" -DVERSION=\"1.80b\" afl-clang-fast.c -o ../afl-clang-fast -Wl,-O1 -Wl,--hash-style=gnu x86_64-pc-linux-gnu-clang-3.6.0: error: unknown argument: '-frecord-gcc-switches' Makefile:64: recipe for target '../afl-clang-fast' failed make: *** [../afl-clang-fast] Error 1 * ERROR: app-forensics/afl-1.80b::gentoo failed (compile phase): * emake failed
Created attachment 411226 [details] build.log
Created attachment 411228 [details] emerge-info.log
I'm not sure what a proper solution here is. The reason afl uses clang is that it has a mode using a clang plugin. That is of course built with clang and not the system's compiler, thereby that's "by design". What fix would you expect?
i also have -frecord-gcc-switches in my CFLAGS and thus the same problem. as i said in bug 561300, ideally this would be handled at some higher level, probably in portage and in the affected packages. basically we need a way to specify different CFLAGS/etc for use with gcc and clang (say, CFLAGS_GCC and CFLAGS_CLANG) and packages would have to substitute the correct one for CFLAGS. this doesn't look like a simple one-liner job and i'm not volunteering myself either, sorry. the alternative is to keep fixing either compiler to at least ignore those switches that are not critical for compilation, but i doubt that either upstream project would want to engage in that endless cat&mouse game.
I agree that the "proper" solution is probably complicated and unlikely to happen soon. But to ease the situation I think we can filter known flags that are likely to cause trouble for the clang part. I would propose something like this (not committed yet, because wanted to give you a chance to comment and maybe propose additional gcc-only flags we should filter): --- /var/portage/app-forensics/afl/afl-1.96b.ebuild 2016-01-03 17:53:09.903331693 +0100 +++ afl-1.96b.ebuild 2016-01-03 17:58:59.202305551 +0100 @@ -4,7 +4,7 @@ EAPI=5 -inherit multilib toolchain-funcs +inherit multilib toolchain-funcs flag-o-matic DESCRIPTION="american fuzzy lop - compile-time instrumentation fuzzer" HOMEPAGE="http://lcamtuf.coredump.cx/afl/" @@ -23,8 +23,8 @@ PREFIX="/usr" \ HELPER_PATH="/usr/$(get_libdir)/afl" \ DOC_PATH="/usr/share/doc/${PF}" - cd llvm_mode - emake \ + filter-flags -frecord-gcc-switches + emake llvm_mode \ PREFIX="/usr" \ HELPER_PATH="/usr/$(get_libdir)/afl" \ DOC_PATH="/usr/share/doc/${PF}"
personally i just do this and other filtering (e.g., -fplugin*) via package.env which is more managable for me. doing this on a per-ebuild basis (over time clang specific use will probably grow) won't scale too well... anyway, you guys are the devs who get to maintain this, so your call ;).
(In reply to Hanno Boeck from comment #3) optional clang plugins should be based on USE flags. always pulling in clang or llvm doesn't make sense on many systems. (In reply to Hanno Boeck from comment #5) it's not that hard to localize CFLAGS with clang and strip-unsupported-flags local clang_flags=$(CC=clang strip-unsupported-flags; echo "${CFLAGS}")
(In reply to SpanKY from comment #7) > it's not that hard to localize CFLAGS with clang and strip-unsupported-flags > > local clang_flags=$(CC=clang strip-unsupported-flags; echo "${CFLAGS}") note that test-flags-* isn't smart enough to handle the -fplugin* family where -fplugin-arg-* makes sense only with -fplugin, so testing them one-by-one produces the wrong result (see bug 519462).
(In reply to PaX Team from comment #8) i don't think that's relevant to this bug
(In reply to SpanKY from comment #9) > (In reply to PaX Team from comment #8) > > i don't think that's relevant to this bug do you know for sure that clang doesn't have similar flags that only make sense in combination?
@spanKY: The clang support isn't really an optional thing. The afl-*-fast stuff is basically the new / recommended variant of afl and the one that should be used. But even without that afl still has afl-clang/afl-clang++ wrappers, so it would depend on clang as a runtime dep anyway. It would theoretically be possible to split that up and provide a gcc-only afl-package, but as this is definitely not recommended I wouldn't want to support that. For the clang CFLAGS I think I'll go with the strip-unsupported-flags solution, that looks like it will resolve most issues and hopefully make Pax Team happy.
I'm now using strip-unsupported-flags. It's not pretty, but I think it fixes the issue (also just had another bug about another flag). As said, I don't consider using clang a bug, because essentially that's the recommended way to use afl and I don't want to support the package in a way that's discouraged to be used.
