On Tue, Feb 13, 2018 at 10:18:05AM +0000, Richard W.M. Jones wrote:
> My build of american-fuzzy-lop fails because clang doesn't
> understand the ‘-mcet -fcf-protection’ flags which seem to be
> added by RPM.
> clang -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection
> -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/lib64/afl\"
> -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.52b\" afl-clang-fast.c -o
> clang-6.0: error: unknown argument: '-mcet'
> clang-6.0: error: unknown argument: '-fcf-protection'
> This suggests a bug in our RPM configuration.
Not much more info about what these flags do, but the change was recorded
here with an opaque "Intel says we need this" rationale:
redhat-rpm-config flags have usually been compatible with both gcc and
clang, so if there's no newer clang that supports this, it feels like
we've a few options
1. Have the RPM spec for apps using clang filter these flags out of
the RPM cflags.
2. Revert the change in redhat-rpm-config so we're compatible with
3. Provide a second macro in redhat-rpm-config that is the cut down
set of cflags which still work with clang, that apps can opt for.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org