* Re: stpcpy() redefined
2013-10-18 20:18 ` Ian Lance Taylor
@ 2013-10-18 22:18 ` LRN
0 siblings, 0 replies; 3+ messages in thread
From: LRN @ 2013-10-18 22:18 UTC (permalink / raw)
To: Binutils
-----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 <lrn1986@gmail.com> 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-----
^ permalink raw reply [flat|nested] 3+ messages in thread