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

Re: [Libevent-users] using libEvent 2.x with Visual C++



On 06/08/2012 01:55 PM, Nick Mathewson wrote:

Looks like I never added evutil_time.c to Makefile.nmake when I added
it to Makefile.am.  Should be fixed in 0ba0683bcfc8652a8c50.

Thanks; that works for me!

I've also taken it a bit further, and added support for OpenSSL to Makefile.nmake. Unfortunately, I don't know nmake very well (I haven't yet looked up how to do conditionals, for example), so my Makefile.nmake is very hacked up right now and not suitable for general use. But if anyone wants to peek at it, in its current ugly state, it's on my "windows-ssl" branch on github at git://github.com/ppelleti/libevent.git

So, after building libevent with ssl, I ran regress.exe, and got this (with boring lines omitted for brevity)

main/methods: [forking] OK
main/version: OK
...
util/monotonic: OK
util/monotonic_precise: OK
util/monotonic_fallback:
  FAIL regress_util.c:1273: assert(evutil_timercmp(&tv[i], &tv[i+1], <))
  [monotonic_fallback FAILED]
bufferevent/bufferevent: [forking] OK
...
iocp/listener/randport: [forking] OK
iocp/listener/error: [forking] OK
ssl/bufferevent_socketpair: [forking] OK
ssl/bufferevent_filter: [forking] OK
ssl/bufferevent_renegotiate_socketpair: [forking]
  FAIL regress_ssl.c:335: assert(test_is_done == 1)
  [bufferevent_renegotiate_socketpair FAILED]
ssl/bufferevent_renegotiate_filter: [forking]
  FAIL regress_ssl.c:335: assert(test_is_done == 1)
  [bufferevent_renegotiate_filter FAILED]
ssl/bufferevent_socketpair_startopen: [forking] OK
ssl/bufferevent_filter_startopen: [forking] OK
ssl/bufferevent_connect: [forking] OK
3/196 TESTS FAILED. (15 skipped)

I poked around in regress_ssl.c a little bit, but haven't yet figured out exactly why the test_is_done assertion is failing. I might look at it some more later. (I'm using OpenSSL 1.0.1c.)

Moving on to a different topic, I just wanted to summarize my experience with the idea I had floated earlier, of using a DLL built with MinGW from a program built with MSVC. In principle, it seems to work, and I got bench.exe compiled with MSVC running successfully with a DLL built with MinGW. There were a number of hurdles, however:

* I modified the Makefile.am, so that it would produce .def files, which are needed in order to create the .lib files needed by MSVC:

http://wyw.dcweb.cn/dllfaq.htm

* The event-config.h generated by MinGW was inappropriate for use by MSVC, because it claimed various header files existed that MSVC doesn't have

* I had to comment out getopt in bench.c, since MSVC doesn't have that, either

* The MinGW build didn't compile evutil_gettimeofday, because MinGW has gettimeofday. But since MSVC doesn't have gettimeofday, it needs evutil_gettimeofday. So I had to hack the MinGW build to include evutil_gettimeofday.

So, it seems possible, but is kind of messy and ugly, so I think for now I'll pursue the "native" approach with Makefile.nmake, instead.

--Patrick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.