Aargh, clicked "Reply" instead of "Reply All". Resending.
On 10/29/15 21:29, John Snow wrote: > > > On 10/29/2015 04:22 PM, John Snow wrote: >> Clang++ 3.5 on Fedora 22 appears to have difficulty tolerating >> D_FORTIFY_SOURCE for certain glibc headers, such as stdio. >> >> This interferes, currently, with any arm target build. >> >> Work around this by disabling FORTIFY_SOURCE for clang builds >> if a problem is observed. >> >> Newer versions of clang such as 3.5.2 (As seen in debian-testing) >> or 3.7.0 (As seen in Fedora 23 Beta) are unaffected and will not >> trigger this workaround. >> >> Signed-off-by: John Snow <js...@redhat.com> >> --- > > As a meta-cover-letter, this fix is a little weird in that it will > disable FORTIFY_SOURCE (silently!) for non-debug builds. Not great. > > (Maybe I could have it fail and print a warning encouraging users to > either use --enable-debug or --disable-fortify-source?) > > Still, It'd be nice to have Clang builds working out of the box for ARM > builds. It just so happens that ARM is the only target that happens to > trip this specific unfortunate chain of events. > > Is it sane to check for clang-and-arm-targets only? Maybe it's a moot > point -- newer (and older, I believe) versions of Clang won't trigger > this at all. > > Anyway, see these links (Dredged up by Laszlo Ersek, thanks!) Thanks for the credit. I didn't notice this patch on the list (and I've been CC'd just now), so I'm unsure if I'm supposed to (try to) review it. If so, then: > https://llvm.org/bugs/show_bug.cgi?id=7219 > https://llvm.org/bugs/show_bug.cgi?id=16821 > https://llvm.org/bugs/show_bug.cgi?id=23277#c2 > > Here's a good takeaway quote: > > 'Also, _FORTIFY_SOURCE + glibc + clang is not supported and does not > work (for instance, it relies on __builtin_va_pack_len and friends, > which we have no intention of supporting), so glibc compatibility is > unlikely to be a strong motivator for a change here.' this quote would be compelling enough for me to disable _FORTIFY_SOURCE when clang is seen, no questions asked. The above is a public no-support statement from an apparently core clang developer, so "it happens to build without errors with version X.Y.Z." just don't cut it. A positive claim (bugzilla comment, release note, etc) would be necessary. ... As far as I'm concerned, of course. :) Cheers Laszlo > > So long story short, we have a weird hacky workaround where we disable > FORTIFY_SOURCE for compilers that don't appear to be able to support it. > > --js > >> configure | 25 ++++++++++++++++++++++++- >> 1 file changed, 24 insertions(+), 1 deletion(-) >> >> diff --git a/configure b/configure >> index 7a1d08d..7abfcc3 100755 >> --- a/configure >> +++ b/configure >> @@ -107,6 +107,11 @@ compile_object() { >> do_cc $QEMU_CFLAGS $local_cflags -c -o $TMPO $TMPC >> } >> >> +compile_cxx_object() { >> + local_cflags="$1" >> + do_cxx $QEMU_CXXFLAGS $local_cflags -c -o $TMPO $TMPC >> +} >> + >> compile_prog() { >> local_cflags="$1" >> local_ldflags="$2" >> @@ -4436,13 +4441,31 @@ if ! compile_object "-Werror"; then >> fi >> >> ########################################## >> +# Test that we can use FORTIFY_SOURCE, >> +# which might break Clang. >> + >> +if test "$debug" = "no"; then >> + cat > $TMPC << EOF >> +#include <cstdio> >> +int main(int argc, char*argv[]) { >> + fprintf(stdout, "Hello World\n"); >> + return 0; >> +} >> +EOF >> + >> + if ! compile_cxx_object "-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2"; then >> + fortify_source="no"; >> + fi >> +fi >> + >> +########################################## >> # End of CC checks >> # After here, no more $cc or $ld runs >> >> if test "$gcov" = "yes" ; then >> CFLAGS="-fprofile-arcs -ftest-coverage -g $CFLAGS" >> LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS" >> -elif test "$debug" = "no" ; then >> +elif test "$debug" = "no" && test "$fortify_source" != "no" ; then >> CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS" >> fi >> >>
