I have three somewhat major concerns;
--- apr_reslist.h (.../1.3.x/include) (revision 889020)
+++ apr_reslist.h (.../1.4.x/include) (revision 889020)
@@ -28,15 +28,10 @@
#include "apr_errno.h"
#include "apr_time.h"
-#if APR_HAS_THREADS
-
/**
* @defgroup APR_Util_RL Resource List Routines
* @ingroup APR_Util
* @{
- * @warning
- * <strong><em>Resource list data types and routines are only available when
- * threads are enabled (i.e. APR_HAS_THREADS is not zero).</em></strong>
*/
So it truly runs without threads on 1.4.x? Or was this a backport that missed
the 1.4.x branch?
--- apu.h.in (.../1.3.x/include) (revision 889020)
+++ apu.h.in (.../1.4.x/include) (revision 889020)
@@ -102,6 +102,10 @@
#define APU_HAVE_FREETDS @apu_have_freetds@
#define APU_HAVE_ODBC @apu_have_odbc@
+#define APU_HAVE_CRYPTO @apu_have_crypto@
+#define APU_HAVE_OPENSSL @apu_have_openssl@
+#define APU_HAVE_NSS @apu_have_nss@
+
#define APU_HAVE_APR_ICONV @have_apr_iconv@
#define APU_HAVE_ICONV @have_iconv@
#define APR_HAS_XLATE (APU_HAVE_APR_ICONV || APU_HAVE_ICONV)
--- apr_crypto.h (.../1.3.x/include) (revision 0)
+++ apr_crypto.h (.../1.4.x/include) (revision 889020)
@@ -0,0 +1,462 @@
[...]
+
+#if APU_HAVE_CRYPTO
+
+#ifndef APU_CRYPTO_RECOMMENDED_DRIVER
+#if APU_HAVE_OPENSSL
+#define APU_CRYPTO_RECOMMENDED_DRIVER "openssl"
+#else
+#if APU_HAVE_NSS
+#define APU_CRYPTO_RECOMMENDED_DRIVER "nss"
+#else
+#if APU_HAVE_MSCNG
+#define APU_CRYPTO_RECOMMENDED_DRIVER "mscng"
+#else
+#if APU_HAVE_MSCAPI
+#define APU_CRYPTO_RECOMMENDED_DRIVER "mscapi"
+#else
+#endif
+#endif
+#endif
+#endif
+#endif
Ok, why four API's listed in apr_crypto.h when the apr.h.in and related
magic know of only *two* API's?
--- apr_hooks.h (.../1.3.x/include) (revision 889020)
+++ apr_hooks.h (.../1.4.x/include) (revision 889020)
@@ -21,6 +21,23 @@
/* For apr_array_header_t */
#include "apr_tables.h"
+#ifdef APR_DTRACE_PROVIDER
+#include <sys/sdt.h>
+#ifndef OLD_DTRACE_PROBE
+#define OLD_DTRACE_PROBE(name) __dtrace_ap___##name()
+#endif
[...]
Are the OLD_DTRACE macros truly dtrace's, or are these actually ours and
perhaps worthy of namespace protection?
