From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31808 invoked by alias); 21 Apr 2009 21:00:56 -0000 Received: (qmail 31785 invoked by uid 22791); 21 Apr 2009 21:00:51 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52,WEIRD_QUOTING X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Apr 2009 21:00:45 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C050B2BAC29 for ; Tue, 21 Apr 2009 17:00:43 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zhCa-sQvqD3u for ; Tue, 21 Apr 2009 17:00:43 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 880122BAC23 for ; Tue, 21 Apr 2009 17:00:43 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E9F22F58C9; Tue, 21 Apr 2009 14:00:32 -0700 (PDT) Date: Tue, 21 Apr 2009 21:00:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFA/commit] prefer in-tree libiconv over the system libiconv Message-ID: <20090421210032.GF23807@adacore.com> References: <20090420183619.GB5858@adacore.com> <20090420213559.GS2904@adacore.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20090420213559.GS2904@adacore.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00573.txt.bz2 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1024 [switching to gdb-patches] The more I kept thinking about it, the more it seemed to make sense to me that we should use in-tree libiconv if present. Right now, we automatically build it, but we cannot use the current configure switch (--with-libiconv-prefix) to force GDB to use the libiconv we just built. That means that an extra switch would be necessary, not just convenient. This patch implements this change. I've only tested it on GNU/Linux at the moment, with and without in-tree libiconv. I get the expected result both times. I'm checked this patch in AdaCore tree, and I should get build results tomorrow. 2009-04-21 Joel Brobecker * acinclude.m4 (AM_ICONV): Prefer in-tree libiconv if present over system iconv. * configure: Regenerate. The diff seems awful, but all I did was move the block for ../libiconv up before we check for iconv in the libc. And I made us check iconv in libc only if we haven't found iconv in ../libiconv. Any objection? -- Joel --bg08WKrSYDhXBjb5 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="in-tree-iconv.diff" Content-length: 3098 commit b29fa82cb5acbb4423a4515f694b22beb7622aa2 Author: Joel Brobecker Date: Tue Apr 21 13:32:27 2009 -0700 * acinclude.m4 (AM_ICONV): Prefer in-tree libiconv if present over system iconv. * configure: Regenerate. diff --git a/gdb/acinclude.m4 b/gdb/acinclude.m4 index 5e77230..320b7dd 100644 --- a/gdb/acinclude.m4 +++ b/gdb/acinclude.m4 @@ -189,47 +189,51 @@ AC_DEFUN([AM_ICONV], am_cv_func_iconv="no, consider installing GNU libiconv" am_cv_lib_iconv=no am_cv_use_build_libiconv=no - # First, try to find iconv in libc. - AC_TRY_LINK([#include -#include ], - [iconv_t cd = iconv_open("",""); - iconv(cd,NULL,NULL,NULL,NULL); - iconv_close(cd);], - am_cv_func_iconv=yes) - # If iconv was not in libc, try -liconv. In this case, arrange to - # look in the libiconv prefix, if it was specified by the user. - if test "$am_cv_func_iconv" != yes; then - am_save_CPPFLAGS="$CPPFLAGS" + # If libiconv is part of the build tree, then try using it over + # any system iconv. + if test -d ../libiconv; then am_save_LIBS="$LIBS" - if test -n "$LIBICONV_INCLUDE"; then - CPPFLAGS="$CPPFLAGS $LIBICONV_INCLUDE" - LIBS="$LIBS $LIBICONV_LIBDIR" - fi - LIBS="$LIBS -liconv" + am_save_CPPFLAGS="$CPPFLAGS" + LIBS="$LIBS $BUILD_LIBICONV_LIBDIR -liconv" + CPPFLAGS="$CPPFLAGS $BUILD_LIBICONV_INCLUDE" AC_TRY_LINK([#include #include ], [iconv_t cd = iconv_open("",""); iconv(cd,NULL,NULL,NULL,NULL); iconv_close(cd);], + am_cv_use_build_libiconv=yes am_cv_lib_iconv=yes am_cv_func_iconv=yes) LIBS="$am_save_LIBS" CPPFLAGS="$am_save_CPPFLAGS" fi - # If that didn't work, try to find libiconv in the build tree. - if test "$am_cv_func_iconv" != yes && test -d ../libiconv; then - am_save_LIBS="$LIBS" + # Next, try to find iconv in libc. + if test "$am_cv_func_iconv" != yes; then + AC_TRY_LINK([#include +#include ], + [iconv_t cd = iconv_open("",""); + iconv(cd,NULL,NULL,NULL,NULL); + iconv_close(cd);], + am_cv_func_iconv=yes) + fi + + # If iconv was not in libc, try -liconv. In this case, arrange to + # look in the libiconv prefix, if it was specified by the user. + if test "$am_cv_func_iconv" != yes; then am_save_CPPFLAGS="$CPPFLAGS" - LIBS="$LIBS $BUILD_LIBICONV_LIBDIR -liconv" - CPPFLAGS="$CPPFLAGS $BUILD_LIBICONV_INCLUDE" + am_save_LIBS="$LIBS" + if test -n "$LIBICONV_INCLUDE"; then + CPPFLAGS="$CPPFLAGS $LIBICONV_INCLUDE" + LIBS="$LIBS $LIBICONV_LIBDIR" + fi + LIBS="$LIBS -liconv" AC_TRY_LINK([#include #include ], [iconv_t cd = iconv_open("",""); iconv(cd,NULL,NULL,NULL,NULL); iconv_close(cd);], - am_cv_use_build_libiconv=yes am_cv_lib_iconv=yes am_cv_func_iconv=yes) LIBS="$am_save_LIBS" --bg08WKrSYDhXBjb5--