Hello, all. I compiled libevent 1.4.13 on Windows (using the free Microsoft Visual C++ 2008 Express Edition) and ran into some issues that I thought I'd pass on.
* The libevent.sln file doesn't work out of the box; it fails to load the test sub-projects because it's looking for .vcproj files that aren't there. (If you open the libevent.dsw file it will create the missing .vcproj files as it upgrades the project file.) * The project statically links the CRT using /MT and /MTd. In various places MS recommends that you dynamically link the CRT unless you "know what you're doing." Although dynamically linking the CRT using /MD and /MDd entails its own issues (with manifest files and such) I think that would still be a better default stance. (I've provided excerpts from two MS pages below that disciss static CRTs.) * The event.h file does this: #ifdef WIN32 #define WIN32_LEAN_AND_MEAN #include <windows.h> #undef WIN32_LEAN_AND_MEAN ... I'd suggest only undefining WIN32_LEAN_AND_MEAN if event.h did the define in the first place; otherwise you might screw up other code. * The Windows code uses snapshots of config.h and event-config.h. They contain the wrong version number: In config.h: /* Version number of package */ #define VERSION "1.3.99-trunk" In event-config.h: /* Version number of package */ #define _EVENT_VERSION "1.3.99-trunk" * The most interesting problem I ran into was the fact that Windows also has an event.h file. Depending on the order in which include directories are searched that can really screw you up. In my case I included evhttp.h; evhttp.h included event.h; and then the file I was compiling failed because ev_int64_t wasn't defined--despite the fact that it should have been. It took a bit of time to sort that out! === I've noted a few small issues, but they were minor; I wanted to point out that getting libevent up and running on Windows was really quite easy. So: well done. === Using the statically linked CRT implies that any state information saved by the C runtime library will be local to that instance of the CRT. For example, if you use strtok, _strtok_l, wcstok, _wcstok_l, _mbstok, _mbstok_l when using a statically linked CRT, the position of the strtok parser is unrelated to the strtok state used in code in the same process (but in a different DLL or EXE) that is linked to another instance of the static CRT. In contrast, the dynamically linked CRT shares state for all code within a process that is dynamically linked to the CRT. This concern does not apply if you use the new more secure versions of these functions; for example, strtok_s does not have this problem. Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. For example, if you call _set_se_translator in an executable that loads the DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, but hardware exceptions generated by code in the main executable will be caught. http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx If you do choose to mix CRT libraries, remember that you have two separate copies of the CRT, with separate and distinct states, so you must be careful about what you try to do across a CRT-boundary. There are many ways to get into trouble with two CRTs. Here are just a few: * There are two separate heaps. You cannot allocate (explicitly with new, malloc, or so on -- or implicitly with strdup, strstreambuf::str, or so on), and then pass the pointer across a CRT-boundary to be freed. * You cannot pass a FILE* or file handle across a CRT-boundary and expect the "stdio low-level IO" to work. * You cannot set the locale in one and expect the other's locale to be set. http://support.microsoft.com/kb/140584 *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
