On 06/06/2012 05:18 PM, Patrick Pelletier wrote:
(since libEvent doesn't seem to have an equivalent to OpenSSL's "applink.c" that bridges between the two compilers' runtimes)(I'd sure like to have one of those, fwiw.)If that's something you'd like, then I might look into that as an alternative to getting libevent itself compiling with MSVC. I'm more of a coder than a build guy, so it seems more in my comfort zone. It should be pretty simple conceptually, although I suspect it will touch a lot of code. So if you don't mind accepting a big patch, I might explore this option.
Actually, it looks like I might be mistaken about it touching a lot of code. From a quick inspection, in fact, I can only find one function, event_base_dump_events(), which passes runtime library objects across the API boundary.
The main things one needs to look out for are:- memory managed by malloc/free, but so far it looks like all of libevent's memory allocation is nicely encapsulated, and I don't see any places where libevent mallocs something the user is expected to free, or vice versa. (And even if this was an issue, libevent already provides a way to replace malloc/realloc/free.)
- FILE* pointers, but the only one I see is the one passed to event_base_dump_events()
- integer file descriptors, of the sort used by open/read/write/close, but I actually don't see any of these being passed into the API functions. evutil_socket_t is passed around all over the place, but on Windows, a socket is not the same thing as a file descriptor, and my understanding is that sockets are handled by the winsock DLL, not by the C runtime library, so there isn't any restriction against passing them between code compiled with different compilers
So, perhaps I've been worrying about nothing. As long as I avoid event_base_dump_events(), it looks like I might just be able to use a mingw-compiled libevent from a Visual C++ program, without any modification. Of course, the next step is for me to test this hypothesis and see if it actually works.
--Patrick *********************************************************************** To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with unsubscribe libevent-users in the body.