configure: Fix build with capabilities
diff mbox

Message ID 1342360440-14328-1-git-send-email-sw@weilnetz.de
State Accepted
Headers show

Commit Message

Stefan Weil July 15, 2012, 1:54 p.m. UTC
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(-)

Comments

Eric Blake July 16, 2012, 3:35 p.m. UTC | #1
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.
Peter Maydell July 16, 2012, 3:40 p.m. UTC | #2
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
Alexander Graf July 16, 2012, 5:24 p.m. UTC | #3
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
Peter Maydell July 16, 2012, 6:28 p.m. UTC | #4
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
Alexander Graf July 16, 2012, 6:33 p.m. UTC | #5
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

Patch
diff mbox

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