From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrud1-00067A-8L for qemu-devel@nongnu.org; Thu, 29 Oct 2015 17:21:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zrucw-0002uI-B5 for qemu-devel@nongnu.org; Thu, 29 Oct 2015 17:20:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrucw-0002tQ-4O for qemu-devel@nongnu.org; Thu, 29 Oct 2015 17:20:54 -0400 From: Laszlo Ersek References: <1446150168-9632-1-git-send-email-jsnow@redhat.com> <563281A8.60604@redhat.com> Message-ID: <56328DB2.5010205@redhat.com> Date: Thu, 29 Oct 2015 22:20:50 +0100 MIME-Version: 1.0 In-Reply-To: <563281A8.60604@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] configure: workaround for Clang 3.5.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, Paolo Bonzini 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 >> --- > > 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 >> +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 >> >>