Most functions in libunwind.h are actually mapped via macros to obscure
function names, so checking for these would require some elaborate test
via AC_LINK_IFELSE(). However, unw_backtrace() seems to be one of the few
actual functions so lets use this for now, even though we don't call it
ourselves later.
Fixes: 016228c158 ("configure: Check for actual functions in libraries
with AC_CHECK_LIB")
The aikpub2 tool has been replaced by pki --pub|--req --keyid hex ..
where keyid indicates the TPM 2.0 private key object handle. Thus
either the public key in PKCS#1 format can be extracted or a PKCS#10
certificate request signed by the TPM private key can be generated.
Checking for `main` produces code like this in the test program:
int
main ()
{
return main ();
;
return 0;
}
This recursive call results in a warning message with some compilers (e.g.
Clang in newer Xcode versions: "all paths through this function will call
itself [-Winfinite-recursion]"), which lets the tests fail when compiling
with -Werror.
With AC_SEARCH_LIBS() we don't succeed if the searched function is a
built-in as the check uses the wrong signature so the built-in will not
be applied (the warning issued by GCC is "conflicting types for built-in
function '...'"). So even if not required, libatomic will be linked if
it is found, which could be problematic if compiling on a separate host
and the target host does not have libatomic installed.
Also, some tests showed that it's more likely that __atomic_and_fetch()
requires linking libatomic than __atomic_load_n() does.
References #1533.
Even if not using caching when running the configure script (-C) this
allows pre-defining the result by setting the environment variable
ss_cv_func_pthread_condattr_setclock_monotonic=yes|no|unknown
before/while running the script.
As the check requires running a test program this might be helpful
when cross-compiling to disable using monotonic time if
pthread_condattr_setclock() is defined but not actually usable with
CLOCK_MONOTONIC.
References #1502.
The versioning scheme used by Python (PEP 440) supports the rcN suffix
but development releases have to be named devN, not drN, which are
not supported and considered legacy versions.
Andreas Steffen