You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2009/12/10 05:37:25 UTC
Prepared to tag apr-util 1.4.1
Just like a week ago, here's the summary of changes to include/ public
interfaces, sans the commentary-only changes in branches/1.4.x/include.
Please review the attached delta of apr-util 1.3.x to 1.4.x and chime in
if you believe this is ready to tag.
Thanks!
Bill
Re: Prepared to tag apr-util 1.4.1
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Dec 10, 2009 at 12:02 AM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
>
> --- 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?
They're ours AFAICT. Also, the embedded _ap_ in the generated probe
name reflects that these were only used within httpd; that should use
the hook namespace.
I'll look through this in the next couple of days. (GROAN)
Re: Prepared to tag apr-util 1.4.1
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2009-12-09 at 23:35 -0600, William A. Rowe Jr. wrote:
> That doesn't begin to explain to me why it differs between the 1.3 and
> 1.4 branches.
BTW, this change was made before branching of 1.4.x, on the trunk. So,
when 1.4.x was created, that was already in there.
--
Bojan
Re: Prepared to tag apr-util 1.4.1
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2009-12-09 at 23:35 -0600, William A. Rowe Jr. wrote:
> That doesn't begin to explain to me why it differs between the 1.3 and
> 1.4 branches. Only why it might differ between 1.x and 2.x. I'm very
> confused.
My guess is that if someone had 1.3.x compiled without threads, having
this functionality in any later version of 1.3.x would suddenly spring
up symbols that didn't exist before. Therefore, anyone linking against
that never version would have trouble linking again with the older
version of 1.3.x.
I believe we are allowed to do things like this between 1.3.x and 1.4.x.
Or is this not what you're asking?
--
Bojan
Re: Prepared to tag apr-util 1.4.1
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
> On Thu, 2009-12-10 at 16:12 +1100, Bojan Smojver wrote:
>> I'm guessing r680514 is the answer. Trunk has essentially the same
>> file, bar namespace changes.
>
> You can also have a look at this:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=24325
That doesn't begin to explain to me why it differs between the 1.3 and 1.4
branches. Only why it might differ between 1.x and 2.x. I'm very confused.
Re: Prepared to tag apr-util 1.4.1
Posted by Bojan Smojver <bo...@rexursive.com>.
On Thu, 2009-12-10 at 16:12 +1100, Bojan Smojver wrote:
> I'm guessing r680514 is the answer. Trunk has essentially the same
> file, bar namespace changes.
You can also have a look at this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=24325
--
Bojan
Re: Prepared to tag apr-util 1.4.1
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2009-12-09 at 23:02 -0600, William A. Rowe Jr. wrote:
> So it truly runs without threads on 1.4.x?
I'm guessing r680514 is the answer. Trunk has essentially the same file,
bar namespace changes.
--
Bojan
Re: Prepared to tag apr-util 1.4.1
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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?
Re: Prepared to tag apr-util 1.4.1
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe Jr. wrote:
> Just like a week ago, here's the summary of changes to include/ public
> interfaces, sans the commentary-only changes in branches/1.4.x/include.
>
> Please review the attached delta of apr-util 1.3.x to 1.4.x and chime in
> if you believe this is ready to tag.
I've made some time tomorrow night to go through the crypto api, if you
can give me another day or two I should be ready to go.
Regards,
Graham
--