This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stpcpy() redefined

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-
>> ../../binutils-
>> ../../binutils- error:
>> redefinition of âstpcpyâ
>>  stpcpy (dest, src)
>>  ^
>> In file included from ../../binutils-
>> /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

> when it should be defined to 1.

> 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. (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,

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! -
Version: GnuPG v1.4.11 (MingW32)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]