SHGetSpecialFolderPath is in Shell32.dll and the RegOpenKey (et al) and
CryptGenRandom (et al) functions are in -ladvapi32.dll. MinGW is "nice"
and brings those in automatically, but specify them explicitly for
other tool chains.
libevent/Makefile.am corrects a typo (thanks to Harlan for spotting it
once we realized make distcheck was broken when building the libevent
tearoff). The result was the include/ev*.h were not distributed nor
installed whether or not --disable-libevent-install was used. This
was introduced with the final round (3/3) of
--disable-libevent-install patch from me.
The main reason for disabling installation is if you're building
libevent as a subpackage for embedding: you want to have your main
package's "make all" build libevent, but you don't want your main
package's "make install" to install libevent.
We had to turn a couple of 32-bit size arguments into 64-bit arguments
or size_t arguments (since otherwise we would have had to do it post
2.0.x-stable, and that would be worse).
NOTE: This is not the official release until I tag it. If you see
this commit, and you decide that Libevent 2.0.8-rc is now
finalized, you might get something besides 2.0.8-rc.
Chris Davis reports that this is also necessary to fix building with
shared libraries on OSX for him. Should fix bug 2997775.
There is probably a better fix for the issues solved by commit
3cbca8661f, but for now, we're trying to get a beta out the door.
It turns out that commit 3cbca8661f broke building with shared
libraries on OSX. Since -no-undefined is only necessary on platforms
like win32, only use it there.
There may be a better fix for this. Should fix bug 2997775.
It would be great to have the manpages come back some time, perhaps
from a refactoring of my asciidoc book, but for now the existing
manpages were the single worst, most incomplete, and most misleading
libevent documentation we had. (Less misleading: the doxygen output,
the header files, and my reference book.)
If you tried to build with automake-1.6 or earlier, we would
previously spit out pages and pages of garbage output. Now, automake
should just say "Hey, I'm not new enough for this."
AC_LIBOBJ is really only meant for defining missing library functions,
not conditional code compilation. Sticking our conditionally compiled
modules in SYS_SRC should make stuff easier to maintain.
Previously, evdns was at the mercy of the user for providing a good
entropy source; without one, it would be vulnerable to various
active attacks.
This patch adds a port of OpenBSD's arc4random() calls to Libevent
[port by Chris Davis], and wraps it up a little bit so we can use it
more safely.
For what it's worth, we are aware that "Copyright $YEAR $NAME" is
sufficient notice of copyright on software under US law and
Internationally, and saying Copyright (c) $YEAR $NAME is a bit nutty.
The character sequence (c) has never been ruled to have the same force
in US law as the actual copyright symbol, and that neither of these
US-specific symbols adds anything of value beyond saying "Copyright"
since the Berne convention took effect in the US back in 1989.
Similarly, saying "all rights reserved" doesn't do anything magical
unless your software goes in a time-warp back to when the Buenos Aires
Convention was the general rule. (And what will they run it on back
then?) And what would even lead you to say "All Rights Reserved" when
you're explicitly granting most of those rights to anybody receiving
the work in accordance with the 3-clause BSD license?
But still the FOSS community retains these ritual notations out of a
kind of cargo-cult lawyering. Who knows? Perhaps one day, if we
write our copyright notices ineptly enough, John Frum will come and
give us a DFSG-compatible license that everybody can get behind.
(Also, I am not a lawyer. The above should not be taken as legal
advice. -- Nick)
This is necessary or useful for a few reasons:
1) Sometimes applications will add and delete the same event more
than once between calls to dispatch. Processing these changes
immediately is needless, and potentially expensive (especially
if we're on a system that makes one syscall per changed event).
Yes, this actually happens in practice for nonpathological
code, such as in cases where the user's callback conditionally
re-adds a non-persistent event, or where draining a buffer
turns off writing and invokes a user callback which adds more
data which in turn re-enabled writing.
2) Sometimes we can coalesce multiple changes on the same fd into
a single syscall if we know about them in advance. For
example, epoll can do an add and a delete at the same time, but
only if we have found out about both of them before we tell
epoll.
3) Sometimes adding an event that we immediately delete can cause
unintended consequences: in kqueue, this makes pending events
get reported spuriously.
The fairness algorithms are not the best, not every bufferevent type
is supported, and some of the locking tricks here are simply absurd.
Still, this code should be a good first step.
