[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] EVENT2_MS_CALLING_CONVENTION Macro Suggestion



On Fri, Mar 25, 2016 at 01:14:24PM +0300, Azat Khuzhin wrote:
> On Wed, Feb 03, 2016 at 01:56:29AM -0500, Shao Miller wrote:
> > Hello, libevent mailing-list.
> > 
> > Here[1] are some steps which helped me to build libevent with Microsoft
> > Windows XP.
> > 
> > The only quirk I've discovered so far is that when I want to use the Windows
> > DDK's "BUILD" program to build a libevent-consuming project, I run into
> > calling convention mismatching...  By default, BUILD seems to want to give
> > /Gz to the compiler, which specifies __stdcall as the default calling
> > convention for functions.  Unfortunately, the steps[1] that I used resulted
> > in a libevent DLL using the __cdecl calling convention.  The compiler would
> > want /Gd, for that.
> > 
> > So what happens is that only one of these will be linked:
> > - libevent (via __cdecl)
> > - Winsock2 (ws2_32, via __stdcall)

Also can you please post error log?

AFAIR I can build libevent with the following configurations, without
patching libevent:
- win-xp mingw32 static
- win-xp mingw32 shared
- win-7  vs2013  static
- win-7  vs2013  shared

> > In a BUILD "sources" file, one can use the following line to request /Gd:
> > 
> >   386_STDCALL=0
> > 
> > But that doesn't help with Winsock2.
> > 
> > Fortunately, Winsock2's header uses WSAAPI to mark the calling convention
> > for its functions.  That preprocesses as "FAR PASCAL", so the following ugly
> > hack gets libevent and Winsock2 to play nicely with BUILD:
> > 
> >   #ifndef WIN32
> >   /* ... */
> >   #else
> >   #include <windows.h>
> >   #define PASCAL __stdcall
> >   #include <winsock2.h>
> >   #endif
> > 
> > The build-log will warn about a redefinition of PASCAL, but oh well.
> 
> #undef PASCAL
> #define PASCAL __stdcall
> 
> > Does anyone think it might be worth-while to introduce an
> > EVENT2_MS_CALLING_CONVENTION macro between the return-type and identifier
> > for each libevent function?  (That's where Microsoft wants it, if I recall
> > correctly.)  Or, if all other implementations use the same convention for
> > the location of such a calling-convention extension, perhaps
> > EVENT2_CALLING_CONVENTION. Hooray for clutter?
> 
> I'm not sure that we should change defaults (since this can break
> some other builds), but can you send a patch (email/github pull-request)
> with that define under #ifdef that generated by cmake/autoconf options
> for this?
> 
> In the mean time I will try to test it under DDK's BUILD.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.