| Message ID | 87sjl35fye.fsf@rho.meyering.net |
|---|---|
| State | Superseded |
| Headers | show |
On Dec 2, 2011, at 7:13 AM, Jim Meyering wrote: > Chuck Lever wrote: >> On Dec 1, 2011, at 7:27 AM, Jim Meyering wrote: >>> From: Jim Meyering <meyering@redhat.com> >>> * configure.ac: Use AM_PROG_AR (must precede LT_INIT). >>> Without this, when using what will soon be automake-1.11.2, we'd >>> get a warning like this for each .a file: > ... >> After applying this on my Fedora 15 build system, I get: >> >> [cel@degas fedfs-utils]$ sh ./autogen.sh >> cleaning up................... done >> configure.ac:35: warning: macro `AM_PROG_AR' not found in library > > I dug a little deeper and discovered that this arises from the > combination of fedfs-utils' use of -Wall and -Werror and my use > of almost-automake-1.11.2. Here's a better patch: > > From c3f1cfcb1506126cf56717ba22abd9537321ae7a Mon Sep 17 00:00:00 2001 > From: Jim Meyering <meyering@redhat.com> > Date: Wed, 30 Nov 2011 20:41:48 +0100 > Subject: [PATCH] build: accommodate our use of -Wall with upcoming > automake-1.11.2 > > * configure.ac: Using the -Wall option with what will soon be > automake-1.11.2 results in a warning like this for each .a file: > automake: warnings are treated as errors > /usr/share/automake-1.11a/am/library.am: warning: `libadmin.a':\ > linking libraries using a non-POSIX > /usr/share/automake-1.11a/am/library.am: archiver requires \ > `AM_PROG_AR' in `configure.ac' > src/libadmin/Makefile.am:26: while processing library `libadmin.a' > That is due to the -Wextra-portability option implied by -Wall. > Since AM_PROG_AR is new to automake-1.11.2, for now just disable > the -Wextra-portability option. Thanks for the research. To decide whether this patch is generally applicable, I'm trying to understand how pervasive this problem is. I think there are a few issues to consider: 1. Will this still be a problem once fedfs-utils is converted to build dynamic libraries instead of static libraries? 2. If this isn't an issue for dynamic libraries, then we only need to worry about 0.7. Do we really need to be worried about 0.7 building without warning with a version of automake that may be released after 0.7 is EOL'd? I suppose disabling automake's extra-portability warnings is probably harmless in that case. 3. Is it possible to specify a POSIX archiver for linking the static libraries instead? 4. Can you say a little about what we lose by disabling automake's extra-portability warnings? > Signed-off-by: Jim Meyering <meyering@redhat.com> > --- > configure.ac | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 2a2052f..b439f3f 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -34,7 +34,10 @@ AC_CONFIG_MACRO_DIR([m4]) > > # Automake and libtools initialization > LT_INIT > -AM_INIT_AUTOMAKE([-Wall -Werror silent-rules]) > + > +# Disable the -Wextra-portability option until developers can all use > +# automake-1.11.2 or newer, at which point we'll use the new AM_PROG_AR instead. I'm leary of ever enabling AM_PROG_AR because, while that eliminates warnings for new versions of automake, it appears to introduce loud warnings for older versions. This makes it somewhat not backwards compatible. So is there ever a safe time to enable AM_PROC_AR for existing software projects? > +AM_INIT_AUTOMAKE([-Wall -Werror silent-rules -Wno-extra-portability]) > > # configure command line options > AC_ARG_WITH([fedfsuser], > -- > 1.7.8.rc4
Chuck Lever wrote: ... > Thanks for the research. To decide whether this patch is generally > applicable, I'm trying to understand how pervasive this problem is. I > think there are a few issues to consider: > > 1. Will this still be a problem once fedfs-utils is converted to > build dynamic libraries instead of static libraries? If you don't use $(AR) that warning/error will not arise, so if you eliminate all lines matching _LIBRARIES = ...\.a$ in all Makefile.am files, then you'll be ok. > 2. If this isn't an issue for dynamic libraries, then we only need > to worry about 0.7. Do we really need to be worried about 0.7 > building without warning with a version of automake that may be > released after 0.7 is EOL'd? I suppose disabling automake's > extra-portability warnings is probably harmless in that case. I hear that automake-1.11.2-beta is expected within weeks. It'd be nice to work error-free with that. An alternative is to leave the warning, but to drop the use of -Werror. > 3. Is it possible to specify a POSIX archiver for linking the > static libraries instead? I don't know off hand, but considering the cost of using -Wno-extra-portability, I don't think it's worth investigating. > 4. Can you say a little about what we lose by disabling automake's > extra-portability warnings? Next to nothing: @item extra-portability extra portability issues related to obscure tools. One example of such a tool is the Microsoft @command{lib} archiver.
On Dec 2, 2011, at 7:13 AM, Jim Meyering wrote: > Chuck Lever wrote: >> On Dec 1, 2011, at 7:27 AM, Jim Meyering wrote: >>> From: Jim Meyering <meyering@redhat.com> >>> * configure.ac: Use AM_PROG_AR (must precede LT_INIT). >>> Without this, when using what will soon be automake-1.11.2, we'd >>> get a warning like this for each .a file: > ... >> After applying this on my Fedora 15 build system, I get: >> >> [cel@degas fedfs-utils]$ sh ./autogen.sh >> cleaning up................... done >> configure.ac:35: warning: macro `AM_PROG_AR' not found in library > > I dug a little deeper and discovered that this arises from the > combination of fedfs-utils' use of -Wall and -Werror and my use > of almost-automake-1.11.2. Here's a better patch: > > From c3f1cfcb1506126cf56717ba22abd9537321ae7a Mon Sep 17 00:00:00 2001 > From: Jim Meyering <meyering@redhat.com> > Date: Wed, 30 Nov 2011 20:41:48 +0100 > Subject: [PATCH] build: accommodate our use of -Wall with upcoming > automake-1.11.2 > > * configure.ac: Using the -Wall option with what will soon be > automake-1.11.2 results in a warning like this for each .a file: > automake: warnings are treated as errors > /usr/share/automake-1.11a/am/library.am: warning: `libadmin.a':\ > linking libraries using a non-POSIX > /usr/share/automake-1.11a/am/library.am: archiver requires \ > `AM_PROG_AR' in `configure.ac' > src/libadmin/Makefile.am:26: while processing library `libadmin.a' > That is due to the -Wextra-portability option implied by -Wall. > Since AM_PROG_AR is new to automake-1.11.2, for now just disable > the -Wextra-portability option. It turns out that 0.7 doesn't enable -Wall or -Werror. Is this patch needed? > Signed-off-by: Jim Meyering <meyering@redhat.com> > --- > configure.ac | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 2a2052f..b439f3f 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -34,7 +34,10 @@ AC_CONFIG_MACRO_DIR([m4]) > > # Automake and libtools initialization > LT_INIT > -AM_INIT_AUTOMAKE([-Wall -Werror silent-rules]) > + > +# Disable the -Wextra-portability option until developers can all use > +# automake-1.11.2 or newer, at which point we'll use the new AM_PROG_AR instead. > +AM_INIT_AUTOMAKE([-Wall -Werror silent-rules -Wno-extra-portability]) > > # configure command line options > AC_ARG_WITH([fedfsuser], > -- > 1.7.8.rc4
Chuck Lever wrote: ... >>>> From: Jim Meyering <meyering@redhat.com> >> Subject: [PATCH] build: accommodate our use of -Wall with upcoming automake-1.11.2 ... > It turns out that 0.7 doesn't enable -Wall or -Werror. Is this patch needed? Good point. I've confirmed that it is not needed there.
diff --git a/configure.ac b/configure.ac index 2a2052f..b439f3f 100644 --- a/configure.ac +++ b/configure.ac @@ -34,7 +34,10 @@ AC_CONFIG_MACRO_DIR([m4]) # Automake and libtools initialization LT_INIT -AM_INIT_AUTOMAKE([-Wall -Werror silent-rules]) + +# Disable the -Wextra-portability option until developers can all use +# automake-1.11.2 or newer, at which point we'll use the new AM_PROG_AR instead. +AM_INIT_AUTOMAKE([-Wall -Werror silent-rules -Wno-extra-portability]) # configure command line options AC_ARG_WITH([fedfsuser],