Autotools: rework to simplify and fix recent issues

[bradh352]

Completely rework the autotools build system, issues have cropped up due to the complexity and could cause issues on even semi-modern Linux systems (Ubuntu 20.04 for example).

Changes include:

• Remove all curl/xc/cares m4 helper files, they go overboard on detections of functions and datatypes. Go back to more plain autoconf macros as they've come a long way over the years.
• Use known systems and heuristics to determine datatypes for functions like send() and recv(), rather than the error prone detection which required thousands of permutations and might still get it wrong.
• Remove unneeded configure arguments like --enable-debug or --enable-optimize, its more common for people to simply pass their own CFLAGS on the command line.
• Only require CARES_STATICLIB definition on Windows static builds, its not necessary ever for other systems, even when hiding non-public symbols.
• Remove some function and definition detections that were never used in c-ares
• The test framework is now embedded into the toplevel configure system, there was no need to chain build the test system as it is never built externally to c-ares.

As a side-effect of the changes, a configure run completes in about 25% of the original time.

This has been tested on various Linux distributions (of varying age), FreeBSD, MacOS, Windows (via MSYS2 with Mingw), and Solaris10/11 (by @dfandrich), AIX 7.3 (by @dfandrich). It is not unlikely that this may have broken more esoteric or legacy systems, and we'll likely need to be ready to accept bug reports and patches, but it has removed over 10k lines of build system code. It is very likely any issues that crop up will add far fewer lines of code to fix such systems.

Fix By: Brad House (@bradh352)

[bradh352]

@dfandrich thanks for that, I've committed that fix

[bradh352]

@dfandrich regarding the setsocknonblock issue, can you provide the output from the configure script? I want to see what headers, functions and definitions were detected.

[dfandrich]

https://gist.github.com/dfandrich/80991fcd2fc6610ae084e2e04a9bd476

[bradh352]

@dfandrich I think my latest commit should fix this, I think fcntl.h was missing.

[dfandrich]

The updated PR compiles fine now on Solaris 11 and Solaris 10. The latter required --disable-dependency-tracking due to the complaint:

config.status: error: Something went wrong bootstrapping makefile fragments
    for automatic dependency tracking.  Try re-running configure with the
    '--disable-dependency-tracking' option to at least be able to build
    the package (albeit without support for automatic dependency tracking).

FWIW I used https://portal.cfarm.net/ machines to test on a number of less-common OSes, which is open for anyone to use.

[bradh352]

Ah, I hadn't heard of cfarm, I'll definitely apply for an account. Any idea if they allow you to hook into say Github actions or Cirrus-ci, or if that's forbidden by ToS?

The --disable-dependency-tracking is odd, which compiler are you using, gcc or sunpro? Also, do you have gnu make as your default make program? I think autotools might not be happy with sun's native make on solaris 10.

[dfandrich]

I don't know offhand if that's allowed, but I doubt there's an SLA and the hosts sometimes go down for extended periods. I was using gmake there because there's no other make in the PATH. configure wants --disable-dependency-tracking for both gcc and Sun's cc, but I've discovered that it's due to that lack of a make that it's failing. Setting the MAKE variable to a working make lets configure complete without this error. Everything builds fine when MAKE is set to either Sun's make (whose binary I found) or GNU make.

[bradh352]

@dfandrich awesome thanks for testing that! I don't suppose you have access to the cfarm AIX system and can test that too? :)

[dfandrich]

PR #674 works without issue using gcc on AIX 3.7.

[bradh352]

@dfandrich did you happen to build and run the test suite on solaris and aix ? Or just tested compilation of the library itself?

[dfandrich]

I didn't try the test suite because gmock wasn't available.

[pkropachev]

I faced with the same problem (gmock) during run configure on tag cares-1_24_0 on Ubuntu 20.04.

commit 972f456f2808b4e4b1730c90ab506f6af5f4c725 (HEAD, tag: cares-1_24_0)

checking for gmock... no
configure: error: Package requirements (gmock) were not met:

No package 'gmock' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables GMOCK_CFLAGS
and GMOCK_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
configure: error: ./configure failed for test

Should we wait for new release tag? I'd like to use officially release code.

[bradh352]

@pkropachev That particular error is expected as of 1.24.0 on all platforms if you don't have google test/gtest/gmock installed. Google changed their recommendation from bundling GoogleTest to instead use an external google test for any applications which use it for their test framework, so we unbundled it with the 1.24.0 release which a lot of package maintainers requested we do.

Either you need to --disable-tests, or install googletest (apt-get install libgmock-dev).

I'm not sure at this point when the next release will be out, if what's currently not released on main is sufficient or if we are going to wait for any additional feature drops.

[pkropachev]

@bradh352, Thanks for explanation! I will try both.