From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23172 invoked by alias); 18 Oct 2013 22:18:39 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 23159 invoked by uid 89); 18 Oct 2013 22:18:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-la0-f43.google.com Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 18 Oct 2013 22:18:36 +0000 Received: by mail-la0-f43.google.com with SMTP id el20so1062563lab.2 for ; Fri, 18 Oct 2013 15:18:33 -0700 (PDT) X-Received: by 10.152.22.35 with SMTP id a3mr166631laf.45.1382134712778; Fri, 18 Oct 2013 15:18:32 -0700 (PDT) Received: from [192.168.4.39] (broadband-95-84-200-156.nationalcablenetworks.ru. [95.84.200.156]) by mx.google.com with ESMTPSA id b6sm3437913lae.0.2013.10.18.15.18.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 15:18:32 -0700 (PDT) Message-ID: <5261B3B6.3070602@gmail.com> Date: Fri, 18 Oct 2013 22:18:00 -0000 From: LRN User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0a1 MIME-Version: 1.0 To: Binutils Subject: Re: stpcpy() redefined References: <52618556.2040909@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00264.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19.10.2013 00:18, Ian Lance Taylor wrote: > On Fri, Oct 18, 2013 at 12:00 PM, LRN wrote: >> >> Recent mingw-w64 added a stpcpy() implementation for sources that >> request appropriate compatibility (_XOPEN_SOURCE or _GNU_C_SOURCE). >> >> This created problems with binutils (or, to be precise, with libintl): >> i686-w64-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -DHAVE_CONFIG_H >> - -I. -I../../binutils-2.23.90.20131017/intl >> ../../binutils-2.23.90.20131017/intl/l10nflist.c >> ../../binutils-2.23.90.20131017/intl/l10nflist.c:445:1: error: >> redefinition of ‘stpcpy’ >> stpcpy (dest, src) >> ^ >> In file included from ../../binutils-2.23.90.20131017/intl/l10nflist.c:30:0: >> /home/lrn/src/mingw-w64-mingw32-native/cross-toolchain/i686-w64-mingw32/include/string.h:56:21: >> note: previous definition of ‘stpcpy’ was here >> __mingw_ovr char *stpcpy(char * __restrict__ _Dest,const char * >> __restrict__ _Source) { return __mingw_stpcpy(_Dest, _Source); } >> ^ >> make[2]: *** [l10nflist.o] Error 1 >> >> Before i try to come up with a patch for this, do you have any >> recommendations on dealing with it? > > Or, what is HAVE_STPCPY in config/intl.h? It's undefined > Sounds like it is not defined Yes. > when it should be defined to 1. Yes. > Look in intl/config.log to > see why the intl/configure script thought that your system did not > have stpcpy, even though it apparently does. configure.ac (well, gettext.m4, actually) uses AC_CHECK_FUNCS() to check for a bunch of functions, including stpcpy(). However, what AC_CHECK_FUNCS() does, is that it checks that a given function can be linked. I.e. it basically just tells the SDK to take a hike, declares a dummy prototype of the function, with almost no headers (except for all of the accumulated AC_DEFINEs) and tries to compile and link the program. This only works when you have a library that provides function that goes by the given name. As of SVN r6346 mingw-w64 provides an implementation of stpcpy() in its libmingwex static supplemental library, because there's no stpcpy() in msvcrt; gcc had built-in stpcpy() for some time, but it just optimizes _some_ corner-cases and falls back to generic stpcpy() in all other cases. To be correct, mingw-w64 actually provides a __mingw_stpcpy() function in that library, and has a macro-guarded inline stpcpy() implementation in string.h, which just calls __mingw_stpcpy(). Thus you only get stpcpy() if you pass the macro guards (_XOPEN_SOURCE, _GNU_SOURCE or _POSIX_C_SOURCE [1]). Sadly, it means that AC_CHECK_FUNCS() is not able to find it. You need to use AC_CHECK_DECL() or something similar (something that includes the needed header - string.h). This is not set in stone, and this problem just highlighted that maybe adding stpcpy() this way was not a good idea, and we'll be better off with a simple stpcpy() in libmingwex, and to hell with the macro requirements. Ktietz doesn't have any strong opinions on this matter, and neither do i. In defense of current approach i do want to point out that straight link tests do not really reflect what happens when you compile actual code (with headers), and reliance on simple linking tests already bites people when compiling for W32 (because it's impossible to check for __stdcall functions this way, and W32 API uses __stdcall everywhere). So maybe not using AC_CHECK_FUNCS would be a good thing. [1] I screwed up with the names in the initial message, disregard them. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJSYbO2AAoJEOs4Jb6SI2CwKEoIAKS1SBn32HCB7GiFwKkVk81n 7sBIU1uEKsj6huuwLBwdI2VCQW5BFy66J9Awnd8luJBf0Uwk9ITrRbF110FhCfe0 ZPDoiC5gGZPSs2YUa/vaTjBpW8B6BDaUGerj7Jg6b+qZ3rs3jFznbYrFlajY48Pr PRh2mO3Z5A74fktQUrTWeMNIQZuA1kXKTu+sLoin9isIdX2vvlXm3bmFxL+6XP23 dz+Y6LBaHdBXeRaFC3J47f11Da1iyR9g0sxyTK8crka+rvjlYkuTtg0W8dSL4EHz FqliilczFEiMHzxNIIr8EwPE1qxn0Ej+AU/ALJuCRP531FrzCf0AmjL1wM2wHQQ= =z8bL -----END PGP SIGNATURE-----