Re: autoconf tests and stdcall name mangling

[Dimitrios Apostolou]

On Wed, 22 May 2013, Dimitrios Apostolou wrote:
> (Not sure which list is relevant, so I'm cross-posting to both mingw-users 
> and autoconf lists)

Not a cross-post after all since mingw-users requires registration. I'd 
appreciate any help from autoconf people, just make sure you don't CC 
mingw-users so that you don't get a bounce (or just reply to this 
message).

> Hello lists,
>
> when I'm cross compiling from linux x86_64 to 32-bit MinGW autoconf refuses 
> to detect getaddrinfo and define HAVE_GETADDRINFO. I've limited the case to 
> the following behaviour:
>
> The "getaddrinfo-link.c" attached file is a simplification of what 
> AC_REPLACE_FUNCS(getaddrinfo) tries to compile and link. It fails to find the 
> symbol because gcc most probably doesn't use proper calling conventions 
> (stdcall). This is demonstrated by the build success of the second attached 
> program. So:
>
> $ i686-w64-mingw32-gcc     -o getaddrinfo-link getaddrinfo-link.c    -lws2_32
> /tmp/cctQtw3q.o:getaddrinfo-link.c:(.text+0xc): undefined reference to 
> `_getaddrinfo'
> collect2: ld returned 1 exit status
> $ i686-w64-mingw32-gcc     -o getaddrinfo-link getaddrinfo-link-2.c 
> -lws2_32
> $
>
> In the second case ("getaddrinfo-link-2.c") compilation is successful because 
> the symbol linked is "address@hidden" which actually exists in ws2_32 
> (verified it with nm). Here is the version of my toolchain:
>
> $ i686-w64-mingw32-gcc --version
> i686-w64-mingw32-gcc (GCC) 4.6.3
>
> Any idea what's the proper way to use AC_REPLACE_FUNCS in this case?
>
>
> Thanks in advance,
> Dimitris