as it complicates things too much. The c-ares build options that we use in
UnrealIRCd cause curl not to recongize c-ares, and the other way around is not
good either. Also, self-compiled ("unrealircd shipped") c-ares may not be
used/required by main unrealircd (thus rm'd) while it is still needed by
self-compiled curled. Blehh, what a mess.
Now we simply don't compile curl with c-ares and rely on cURL to enable async
DNS support via system c-ares or via the another way, with the use of threads,
which is standard in curl now for many years and should work on most, if not
all platforms.
If this is somehow problematic for you then install libcurl/libcurl-dev(el)
on your system itself, via your package manager or other means.
./configure script from us. That is, using the correct private lib dir
and using --disable-tests and so on.
Should fix a bug on CentOS where c-ares could not be built due to
the test suite requirements from c-ares, reported by Bun-Bun.
because so many people had a broken system/wget/curl, that is: without
the appropriate trusted CA certificates installed. If this is still
the case, then: too bad. People who DO have a proper setup shouldn't
be held back with regards to security by such users.
First of all, system-wide curl is much preffered, but if not available
then UnrealIRCd will offer to install curl for you during ./Config.
The prompt looks the same as before but we no longer install the curl
library in ~/curl but rather in ~/unrealircd/lib (or wherever you put
your installation).
Basically, it now behaves exactly the same as c-ares, TRE and PCRE.
Downside: curl will be re-compiled each time you re-run ./Config
Upside: curl will be re-compiled each time... :D.. will thus be kept
more up to date.
**
Also: complain if <curlinstall>/bin/curl-config cannot be found.
This ensures we error after ./Config rather than after the whole of
configure has been ran.
Bram Matthys