By Azat Khuzhin (2) and fanquake (1)
* macos-brew-openssl-v2:
Add autodetection of openssl via brew into build matrix
cmake: find openssl prefix via brew
autotools: attempt to find OpenSSL via homebrew on macOS
Closes: #1050 (cherry picked one patch from it)
When compiling for macOS, where users will likely have OpenSSL installed
via brew, rather than available on the system, use brew --prefix to
figure out where OpenSSL is, and then augment the pkg-config path so
that libs are found.
We cannot use the same trick with external declaration,
since there are copy of bufferevent_ops_ssl in each library:
- openssl
- mbedlts
However we can just compare the name of the bufferevent type for now.
(It is totally fine to use memcmp() here since it will be optimized by the compiler).
At the very beginning we reset the bufferevent fd (if bev has it), which
is not a good idea, since if user passes bufferevent with existing fd he
has some intention.
So we need to:
- use BEV_OPT_CLOSE_ON_FREE for default bufferevent_socket_new() (to
avoid manual shutdown/closee)
- drop getsockopt(SOL_SOCKET, SO_ERROR), since bufferevent already has
evutil_socket_finished_connecting_()
- drop supperior bufferevent_setfd(bev, -1) in
evhttp_connection_connect_()
Closes: #795
Refs: #875
As pointed by @kloczek:
"With only two characters it would be harder to guess under what kind of name are libevent lvl 3 man pages.
Longer name with bash/fix/zsh tab competition should not be a problem :)"
Refs: #1099
This will:
- avoid overlapping (since there is util.h.3 page)
- group everything under some prefix (man le_<TAB><TAB> will show everything)
Fixes: #1099
WIth MAN_LINKS=YES doxygen will generate ton's of man pages for each
field, function and so on, but it will not contain anything useful
except for link to another man page (header).
So to avoid man pages clashing, disable MAN_LINKS, and this will
generate man pages only for explicitly documented parts.
But even after this we have pretty non-unique man pages names:
$ find install/ -name '*.3'
install/share/man/man3/util.h.3
...
Looks like we should add prefix for each of them...
But let's see if there will be a problem.
Fixes: #1097
The problem with this man pages are:
- they are likely outdated
- they don't have install target
- and besides quality of man pages generated by doxygen not worse
Was not noticed since it is reported only with optimization enabled, as
stated in gcc(1):
The effectiveness of some warnings depends on optimizations also
being enabled. For example -Wsuggest-final-types is more effective with
link-time optimization and -Wmaybe-uninitialized does not warn at all
unless optimization is enabled.
And interesting thing is that it is reported only for -O2, not for -O3,
that's why I did not catched it in both cmake env that I had:
- debug (it has -O0)
- release (it has -O3)
While autoconf has -O2.
yuangongji:
"Fix CI failures #1071
- Install vcpkg through the source code to temporarily solve the windows CI problem.
- Update cache version and replace setup-msys2."
* upstream/pr/1074:
fix CI:Update cache version and replace setup-msys2
fix CI: Install vcpkg through the source code to temporarily solve the windows CI problem
fixes#1058
GetTempFileNameA() takes an optional prefix, and a "unique" long value
which can optionally be zero, which causes it to automatically
increment until a not-yet-existing filename is found.
When libevent creates many AF_UNIX socketpairs on windows,
it slows down dramatically, due to always using the same blank prefix,
and GetTempFileNameA() needing to iterate through all the existing
socketpair filenames. With a present and varying prefix, it will have
much less need to iterate.
It was also possible for a race with other processes also using
blank-prefix tmpfile names to result in both trying to start using
the same name at the same time (because libevent deletes the file
and then re-creates it as a unix socket), which should now be
much less likely.
Unfortuantely, "much" is just a factor of 32k, because the prefix
is only 3 characters, and windows filesystems are case-insensitive,
so doing better would require more sophisticated windows API usage
and charset trickyness.
