On an ~arch system, unrealircd-3.2.3-r1 fails to build with the curl use flag enabled. This is due to the configure script looking for a -lares that does not exist. The ebuild has a check to make sure people build curl with ares support enabled, however currently only the x86 architecture really does anything with the ares use flag in the curl ebuild. Also since we're using net-dns/c-ares for our ares library, it should be noted that all versions of c-ares currently in portage do not provide a -lares but rather a -lcares. If you edit the configure script for unrealircd to use -lcares instead of -lares, it will then at least build with the curl use flag enabled (even though in my case curl itself was not built with ares support enabled due to the logic in the curl ebuild). Whether curl support in unrealircd works is another story as I haven't tested.
If curl is properly compiled with USE="ares -ipv6" for ares support, curl-config will output the following: morpheus ~ # curl-config --libs -L/usr/lib -lcurl -L/usr/lib -lssl -lcrypto -ldl -lz -lcares UnrealIRCd uses curl-config and will only use -lares if the --libs output from curl-config doesn't include ares. Sure, -lares is wrong and I'm going to fix his, but if all is properly setup this fallback should never be used. And linking to -lcares even if curl was compiled without it doesn't gain anything. It's libcurl that needs ares for asynchronous resolving, else UnrealIRCD may block when fetching the configuration files on /rehash, which is pretty bad. Best would be to make the curl support only active for x86, matching the logic from curl.
curl-7.15.0 solves this problem as the ares use flag is no longer soley dependent on x86. Please feel free to resolve the bug as unrealircd emerges just fine now.
You guys mind if I resolve this since this bug is fixed?
closing
