| Message ID | 1342360440-14328-1-git-send-email-sw@weilnetz.de |
|---|---|
| State | Accepted |
| Headers | show |
On 07/15/2012 07:54 AM, Stefan Weil wrote: > Since commit 417c9d72d48275d19c60861896efd4962d21aca2 all configure tests > normally run with -Werror. Some of these tests now fail because they > raised a compiler warning. > > This patch fixes support for capabilities. > > Signed-off-by: Stefan Weil <sw@weilnetz.de> > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index f745cc2..abde4c0 100755 > --- a/configure > +++ b/configure > @@ -2082,7 +2082,7 @@ if test "$cap" != "no" ; then > cat > $TMPC <<EOF > #include <stdio.h> > #include <sys/capability.h> > -int main(void) { cap_t caps; caps = cap_init(); } > +int main(void) { cap_t caps; caps = cap_init(); return caps != NULL; } Nothing wrong with this patch, per se, but in the Autoconf world, the general advice is that programs should check whether -Werror is supported, but then avoid using it for the entire remainder of the configure script (that is, store the result of -Werror into a different variable that gets added into the final CFLAGS at make time, but not used during any of the rest of the configure time). That's because it's just too hard to avoid warnings-turned-into-errors for all possible versions (including future releases) of gcc, so you are just too likely to run into spurious changes in configurations when the next version of gcc starts warning about something new if you try to run all your configure tests with -Werror.
On 16 July 2012 16:35, Eric Blake <eblake@redhat.com> wrote: > On 07/15/2012 07:54 AM, Stefan Weil wrote: >> Since commit 417c9d72d48275d19c60861896efd4962d21aca2 all configure tests >> normally run with -Werror. Some of these tests now fail because they >> raised a compiler warning. > Nothing wrong with this patch, per se, but in the Autoconf world, the > general advice is that programs should check whether -Werror is > supported, but then avoid using it for the entire remainder of the > configure script (that is, store the result of -Werror into a different > variable that gets added into the final CFLAGS at make time, but not > used during any of the rest of the configure time). That's because it's > just too hard to avoid warnings-turned-into-errors for all possible > versions (including future releases) of gcc, so you are just too likely > to run into spurious changes in configurations when the next version of > gcc starts warning about something new if you try to run all your > configure tests with -Werror. Hmm, good point -- unlike the actual program compile, failures due to -Werror inside configure are silent and near-invisible. Maybe we should back out 417c9d72 ? -- PMM
On 07/16/2012 05:40 PM, Peter Maydell wrote: > On 16 July 2012 16:35, Eric Blake <eblake@redhat.com> wrote: >> On 07/15/2012 07:54 AM, Stefan Weil wrote: >>> Since commit 417c9d72d48275d19c60861896efd4962d21aca2 all configure tests >>> normally run with -Werror. Some of these tests now fail because they >>> raised a compiler warning. >> Nothing wrong with this patch, per se, but in the Autoconf world, the >> general advice is that programs should check whether -Werror is >> supported, but then avoid using it for the entire remainder of the >> configure script (that is, store the result of -Werror into a different >> variable that gets added into the final CFLAGS at make time, but not >> used during any of the rest of the configure time). That's because it's >> just too hard to avoid warnings-turned-into-errors for all possible >> versions (including future releases) of gcc, so you are just too likely >> to run into spurious changes in configurations when the next version of >> gcc starts warning about something new if you try to run all your >> configure tests with -Werror. > Hmm, good point -- unlike the actual program compile, failures > due to -Werror inside configure are silent and near-invisible. > Maybe we should back out 417c9d72 ? So how do we deal with the original problem then? The one where the build broke for me because the smartcard code got compiled in because configure didn't know that it would fail to compile with -Werror? Alex
On 16 July 2012 18:24, Alexander Graf <agraf@suse.de> wrote: > On 07/16/2012 05:40 PM, Peter Maydell wrote: >> Hmm, good point -- unlike the actual program compile, failures >> due to -Werror inside configure are silent and near-invisible. >> Maybe we should back out 417c9d72 ? > > So how do we deal with the original problem then? The one where the build > broke for me because the smartcard code got compiled in because configure > didn't know that it would fail to compile with -Werror? We could have a specific configure check for "can you include this header file in a -Werror compilation", I guess? -- PMM
On 16.07.2012, at 20:28, Peter Maydell wrote: > On 16 July 2012 18:24, Alexander Graf <agraf@suse.de> wrote: >> On 07/16/2012 05:40 PM, Peter Maydell wrote: >>> Hmm, good point -- unlike the actual program compile, failures >>> due to -Werror inside configure are silent and near-invisible. >>> Maybe we should back out 417c9d72 ? >> >> So how do we deal with the original problem then? The one where the build >> broke for me because the smartcard code got compiled in because configure >> didn't know that it would fail to compile with -Werror? > > We could have a specific configure check for "can you include > this header file in a -Werror compilation", I guess? That's what my first patch did. Alex
diff --git a/configure b/configure index f745cc2..abde4c0 100755 --- a/configure +++ b/configure @@ -2082,7 +2082,7 @@ if test "$cap" != "no" ; then cat > $TMPC <<EOF #include <stdio.h> #include <sys/capability.h> -int main(void) { cap_t caps; caps = cap_init(); } +int main(void) { cap_t caps; caps = cap_init(); return caps != NULL; } EOF if compile_prog "" "-lcap" ; then cap=yes
Since commit 417c9d72d48275d19c60861896efd4962d21aca2 all configure tests normally run with -Werror. Some of these tests now fail because they raised a compiler warning. This patch fixes support for capabilities. Signed-off-by: Stefan Weil <sw@weilnetz.de> --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)