git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Blake Ramsdell <blaker@gmail.com>,
	Wincent Colaiuta <win@wincent.com>,
	Junio C Hamano <gitster@pobox.com>, Pascal Obry <pascal@obry.net>,
	Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
	Arjen Laarhoven <arjen@yaph.org>,
	Brian Gernhardt <benji@silverinsanity.com>,
	Jakub Narebski <jnareb@gmail.com>
Subject: [PATCH/RFC (take 3)] autoconf: Add test for OLD_ICONV (squelching compiler warning)
Date: Fri,  7 Dec 2007 02:27:20 +0100	[thread overview]
Message-ID: <1196990840-1168-1-git-send-email-jnareb@gmail.com> (raw)
In-Reply-To: <alpine.LFD.0.9999.0712061628070.13796@woody.linux-foundation.org>

Update configure.ac (and config.mak.in) to keep up with git
development by adding [compile] test whether your library has an old
iconv(), where the second (input buffer pointer) parameter is declared
with type (const char **) (OLD_ICONV).

Test-proposed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
CC-ed to all parties (in this and previous thread).

I should probably used AC_LANG_PROGRAM like for NO_C99_FORMAT instead
of generating whole programlet^W test program by hand (I hope that for
example I haven't missed some header file which needs to be included);
I have followed example for NO_ICONV / NEEDS_LIBICONV and
NO_DEFLATE_BOUND test.  I'm also not sure if I have put this test in
the correct autoconf section, but that is probably matter of taste.

On Fri, 7 Dec 2007, Linus Torvalds wrote:
> 
> On Fri, 7 Dec 2007, Jakub Narebski wrote:
>>
>> The problem is that it should be check that tests for compile time 
>> _warnings_; my solution was to use '-Werror' flag to make warning into 
>> error, and AC_COMPILE_IFELSE, but this might be gcc only solution.
>> 
>>   Message-ID: <1196895948-25115-1-git-send-email-jnareb@gmail.com>
>>   http://permalink.gmane.org/gmane.comp.version-control.git/67209
>> 
>> So please send it.
> 
> Umm. Why not just make the test be whether the following compiles cleanly?
> 
> 	#include <iconv.h>
> 	
> 	extern size_t iconv(iconv_t cd,
> 	  char **inbuf, size_t *inbytesleft,
> 	  char **outbuf, size_t *outbytesleft);
> 
> because if the compiler has seen a "const char **inbuf", then it  should 
> error out with a "conflicting types for ?iconv?" style message..

[...]

> Totally untested. I don't do autoconf.

Thanks for a suggestion. Implemented in the patch below. It should
work correctly, but could those who have old iconv(), or used to have
old iconv() please check if works correctly for them?

By the way, perhaps the previous idea would work using AC_LANG_WERROR
instead of passing adding [temporarily] GCC `-Werror' option to
`CFLAGS', or use parts of its implementation.

 - Macro: AC_LANG_WERROR
     Normally Autoconf ignores warnings generated by the compiler,
     linker, and preprocessor.  If this macro is used, warnings will be
     treated as fatal errors instead for the current language.  This
     macro is useful when the results of configuration will be used
     where warnings are unacceptable; for instance, if parts of a
     program are built with the GCC `-Werror' option.  If the whole
     program will be built using `-Werror' it is often simpler to put
     `-Werror' in the compiler flags (`CFLAGS' etc.).


On Fri, 7 Dec 2007, Blake Ramsdell wrote:
> On Dec 6, 2007 4:41 PM, Blake Ramsdell <blaker@gmail.com> wrote:
>> On Dec 6, 2007 4:30 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>> Umm. Why not just make the test be whether the following compiles cleanly?
>>>
>>>         #include <iconv.h>
>>>
>>>         extern size_t iconv(iconv_t cd,
>>>           char **inbuf, size_t *inbytesleft,
>>>           char **outbuf, size_t *outbytesleft);
>>>
>>> because if the compiler has seen a "const char **inbuf", then it  should
>>> error out with a "conflicting types for 'iconv'" style message..
>>
>> Yeah, this is what I did:
> 
> My apologies. Your suggestion is completely different, and should work
> without -Werror. Let me try that.

Is something like the patch below what you wanted to try?

 config.mak.in |    1 +
 configure.ac  |   22 ++++++++++++++++++++++
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/config.mak.in b/config.mak.in
index 11d256e..7d5df9b 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -41,4 +41,5 @@ NO_STRTOUMAX=@NO_STRTOUMAX@
 NO_SETENV=@NO_SETENV@
 NO_MKDTEMP=@NO_MKDTEMP@
 NO_ICONV=@NO_ICONV@
+OLD_ICONV=@OLD_ICONV@
 NO_DEFLATE_BOUND=@NO_DEFLATE_BOUND@
diff --git a/configure.ac b/configure.ac
index 5f8a15b..86be19a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -212,6 +212,28 @@ test -n "$NEEDS_SOCKET" && LIBS="$LIBS -lsocket"
 
 
 ## Checks for header files.
+AC_MSG_NOTICE([CHECKS for header files])
+#
+# Define OLD_ICONV if your library has an old iconv(), where the second
+# (input buffer pointer) parameter is declared with type (const char **).
+AC_DEFUN([OLDICONVTEST_SRC], [[
+#include <iconv.h>
+
+extern size_t iconv(iconv_t cd,
+                    char **inbuf, size_t *inbytesleft,
+                    char **outbuf, size_t *outbytesleft);
+
+int main(void)
+{
+	return 0;
+}
+]])
+AC_MSG_CHECKING([for old iconv()])
+AC_COMPILE_IFELSE(OLDICONVTEST_SRC,
+	[AC_MSG_RESULT([no])],
+	[AC_MSG_RESULT([yes])
+	OLD_ICONV=UnfortunatelyYes])
+AC_SUBST(OLD_ICONV)
 
 
 ## Checks for typedefs, structures, and compiler characteristics.
-- 
1.5.3.7

  parent reply	other threads:[~2007-12-07  1:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-06 19:07 [PATCH] Silence iconv warnings on Leopard Wincent Colaiuta
2007-12-06 23:04 ` Blake Ramsdell
2007-12-07  0:11   ` Jakub Narebski
2007-12-07  0:12     ` Blake Ramsdell
2007-12-07  0:30     ` Linus Torvalds
2007-12-07  0:41       ` Blake Ramsdell
2007-12-07  0:44         ` Blake Ramsdell
2007-12-07  1:27       ` Jakub Narebski [this message]
2007-12-07  7:26         ` [PATCH/RFC (take 3)] autoconf: Add test for OLD_ICONV (squelching compiler warning) Junio C Hamano
2007-12-07  8:25           ` Wincent Colaiuta
2007-12-07  8:22         ` Wincent Colaiuta
2007-12-07  8:29         ` Blake Ramsdell

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=1196990840-1168-1-git-send-email-jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=arjen@yaph.org \
    --cc=benji@silverinsanity.com \
    --cc=blaker@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pascal@obry.net \
    --cc=ramsay@ramsay1.demon.co.uk \
    --cc=torvalds@linux-foundation.org \
    --cc=win@wincent.com \
    /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).