Dear all,
It seems AC_PROG_CC wrongly believes clang is gcc and that may cause problems
when clang is passed a warning which is only supposrted by gcc, as is
the case e.g. for -Wno-stringop-truncation.
Is there a recommended way to determine for sure from a configure script
whether the detected C
On Fri, 05 Feb 2021 15:42:28 +0100, =?utf-8?Q?S=C3=A9bastien?= Hinderer wrote:
> It seems AC_PROG_CC wrongly believes clang is gcc and that may cause problems
> when clang is passed a warning which is only supposrted by gcc, as is
> the case e.g. for -Wno-stringop-truncation.
clang also defines _
Many thanks Todd for your helpful response!
Sébastien.
On Feb 5, 2021, at 9:51 AM, Todd C. Miller
wrote:
On Fri, 05 Feb 2021 15:42:28 +0100, =?utf-8?Q?S=C3=A9bastien?=
Hinderer wrote:
It seems AC_PROG_CC wrongly believes clang is gcc and that may cause
problems
when clang is passed a warning which is only supposrted
> On Feb 5, 2021, at 9:51 AM, Todd C. Miller wrote:
>
> On Fri, 05 Feb 2021 15:42:28 +0100, =?utf-8?Q?S=C3=A9bastien?= Hinderer wrote:
>
>> It seems AC_PROG_CC wrongly believes clang is gcc and that may cause problems
>> when clang is passed a warning which is only supposrted by gcc, as is
>>
Sébastien Hinderer writes:
> It seems AC_PROG_CC wrongly believes clang is gcc and that may cause
> problems when clang is passed a warning which is only supposrted by gcc,
> as is the case e.g. for -Wno-stringop-truncation.
> Is there a recommended way to determine for sure from a configure scr
"David A. Wheeler" writes:
> The gcc & clang groups coordinate with each other; they try to provide
> the same flags & API for the same functionality, and occasionally copy
> from each other.
This is not my experience. In particular, the warning flags for Clang are
significantly different than
