I've been seeing this bug crop up in many circles: https://bugzilla.redhat.com/show_bug.cgi?id=1099282
Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix?
On Thu, May 29, 2014 at 04:28:18PM -0400, Tim St Clair wrote:
I've been seeing this bug crop up in many circles: https://bugzilla.redhat.com/show_bug.cgi?id=1099282
Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix?
If you're building RPMs locally, you can drop your own definition of __global_cflags into '~/.rpmmacros':
%__global_cflags -O2 -g ..etc..
If you are building a package that uses an autoconf-generated configure script, then simply setting CFLAGS before running configure should be enough, eg:
CFLAGS="$( rpm --eval '%{__global_cflags}' | sed 's/-fstack-protector-strong//' )" \ ./configure
Rich.
On 05/29/2014 10:28 PM, Tim St Clair wrote:
I've been seeing this bug crop up in many circles: https://bugzilla.redhat.com/show_bug.cgi?id=1099282
Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix?
I think FPC (and/or FESCO) should decide on whether we want to allow/disallow using clang for official Fedora rpms.
I for one am in favor of system-wide consistency and thus am in favor of banning such use cases in official Fedora rpms.
Ralf
On Fri, May 30, 2014 at 10:25:28AM +0200, Ralf Corsepius wrote:
On 05/29/2014 10:28 PM, Tim St Clair wrote:
I've been seeing this bug crop up in many circles: https://bugzilla.redhat.com/show_bug.cgi?id=1099282
Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix?
I think FPC (and/or FESCO) should decide on whether we want to allow/disallow using clang for official Fedora rpms.
https://fedorahosted.org/fesco/ticket/847 http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-...
?
Jakub
I'm primarily referring to development compilation, not necessarily packaging.
The default CFLAGS cause clang to fail 'out of the gate'. Given the popularity rise in the compiler, and the increase # of open tickets upstream around this issue, I think it prudent that we address.
Not to change the whole packaging infrastructure, just so developers can install the tools and test their builds.
Cheers, Tim
----- Original Message -----
From: "Jakub Jelinek" jakub@redhat.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Cc: "Discussion of RPM packaging standards and practices for Fedora" packaging@lists.fedoraproject.org Sent: Friday, May 30, 2014 4:03:57 AM Subject: Re: fedoras default cflags & clang
On Fri, May 30, 2014 at 10:25:28AM +0200, Ralf Corsepius wrote:
On 05/29/2014 10:28 PM, Tim St Clair wrote:
I've been seeing this bug crop up in many circles: https://bugzilla.redhat.com/show_bug.cgi?id=1099282
Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix?
I think FPC (and/or FESCO) should decide on whether we want to allow/disallow using clang for official Fedora rpms.
https://fedorahosted.org/fesco/ticket/847 http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-...
?
Jakub
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Fri, 2014-05-30 at 10:03 -0400, Tim St Clair wrote:
I'm primarily referring to development compilation, not necessarily packaging.
The default CFLAGS cause clang to fail 'out of the gate'. Given the popularity rise in the compiler, and the increase # of open tickets upstream around this issue, I think it prudent that we address.
I don't think it's reasonable to hold Fedora hostage to clang's subset of gcc. I'd be fine with adding hacks to clang to accept-but-ignore cflags it didn't know about (or in the -fstack-protector-strong case, alias it to -fstack-protector). But taking things out of the default cflags that clang doesn't support isn't my favorite idea.
(I also think packages building with clang in koji should be at least explicitly tracked, but they kinda already are, because you'll have BuildRequires: clang{-devel}.)
- ajax
Il 30/05/2014 11:03, Jakub Jelinek ha scritto:
Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix?
I think FPC (and/or FESCO) should decide on whether we want to allow/disallow using clang for official Fedora rpms.
https://fedorahosted.org/fesco/ticket/847 http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-...
FWIW, the IRC meeting log mentioned the famous page about better clang diagnostics. That page is comparing clang against GCC 4.2 (Fedora 8 or so).
As of 2014, I only know two cases where clang is still better: more complete caret diagnostics, and better recovery from invalid types (clang provides suggestions and uses it for the rest of the compilation to avoid cascaded error messages).
As of 2014, clang's main strength over GCC is the static analyzer, not the diagnostics or the optimization.
Paolo
On Sat, 31 May 2014 00:31:50 +0200, Paolo Bonzini wrote:
As of 2014, I only know two cases where clang is still better: more complete caret diagnostics, and better recovery from invalid types (clang provides suggestions and uses it for the rest of the compilation to avoid cascaded error messages).
wrong caret / lineno for wrong ctor field initializer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59621
diagnostics: missing proper file:line on C++ compilation error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58589
Jan
2014-05-29 22:28 GMT+02:00 Tim St Clair tstclair@redhat.com:
I've been seeing this bug crop up in many circles: https://bugzilla.redhat.com/show_bug.cgi?id=1099282
At a first glance this seems like a bug in llvm-config, nothing obviously related to “default” cflags.
http://llvm.org/docs/CommandGuide/llvm-config.html says llvm-config is supposed to return flags “needed to link against LLVM”, and AFAIK -fstack-protector-strong doesn’t affect ABI so doesn’t need to be returned by llvm-config in the first place. Mirek