From: Michael Haggerty <mhagger@alum.mit.edu>
To: git discussion list <git@vger.kernel.org>
Subject: Compiling git with -Werror
Date: Fri, 27 Apr 2012 11:45:20 +0200 [thread overview]
Message-ID: <4F9A6AB0.1050504@alum.mit.edu> (raw)
I like to develop with errors and warnings turned up as strict as
possible. For example, I would like to use
CFLAGS="-g -O2 -Wall -Werror -Wdeclaration-after-statement"
I thought this would be as simple as
git clean -fdx
make configure
./configure CFLAGS="-g -O2 -Wall -Werror -Wdeclaration-after-statement"
make
# hack
make
# hack
# etc.
but the "make" step results in an error:
> $ make
> * new build flags or prefix
> CC daemon.o
> In file included from cache.h:4:0,
> from daemon.c:1:
> git-compat-util.h:359:0: error: "strtok_r" redefined [-Werror]
> /usr/include/x86_64-linux-gnu/bits/string2.h:1196:0: note: this is the location of the previous definition
> cc1: all warnings being treated as errors
> make: *** [daemon.o] Error 1
The cause of the problem is that the CFLAGS variable is used by
./configure when it is running its tests, and some of the tests don't
work correctly (they produce results that are not correct for the
platform) when run with the strict CFLAGS. For example, in the broken
case config.log contains
> configure:4592: cc -o conftest -g -O2 -Wall -Werror -Wdeclaration-after-statement conftest.c -lc >&5
> conftest.c:16:6: error: conflicting types for built-in function 'gettext' [-Werror]
> cc1: all warnings being treated as errors
> configure:4592: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "git"
> | #define PACKAGE_TARNAME "git"
> | #define PACKAGE_VERSION "1.7.10.362.g010b2"
> | #define PACKAGE_STRING "git 1.7.10.362.g010b2"
> | #define PACKAGE_BUGREPORT "git@vger.kernel.org"
> | #define PACKAGE_URL ""
> | /* end confdefs.h. */
> |
> | /* Override any GCC internal prototype to avoid an error.
> | Use char because int might match the return type of a GCC
> | builtin and then its argument prototype would still apply. */
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char gettext ();
> | int
> | main ()
> | {
> | return gettext ();
> | ;
> | return 0;
> | }
> configure:4601: result: no
It is possible to work around this problem by passing the CFLAGS value
to make rather than configure:
git clean -fdx
make configure
./configure
make CFLAGS="-g -O2 -Wall -Werror -Wdeclaration-after-statement"
# hack
make CFLAGS="-g -O2 -Wall -Werror -Wdeclaration-after-statement"
# hack
# etc.
but it is annoying to need such a long command line for "make" (not to
mention that I run make from the command line, from emacs, etc. and
would have to adjust the command line everywhere). Or the CFLAGS could
be put into an environment variable, but this again would have to be set
up separately (and consistently!) for every terminal and emacs sessions
that is in use.
Is there some other mechanism to set strict CFLAGS parameters for the
build without confusing ./configure?
Is this a bug in how the git project is using autoconf?
Is it a bug in autoconf itself?
Thanks,
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
next reply other threads:[~2012-04-27 9:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 9:45 Michael Haggerty [this message]
2012-04-27 9:58 ` Compiling git with -Werror Thomas Rast
2012-04-27 10:07 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F9A6AB0.1050504@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).