Re: apr-util v1.7: request for more testing

[Graham Leggett via dev]

On 20 Mar 2025, at 16:12, Rainer Jung  wrote:

> Am 20.03.25 um 16:34 schrieb Graham Leggett via dev:
>> On 20 Mar 2025, at 15:08, Graham Leggett  wrote:
> ...
>> To sum up:
>> - httpd-trunk + apr-trunk - old API and new API will not build by definition.
>> - httpd-trunk + apr-trunk + https://github.com/apache/httpd/pull/438: 
>>  new API and new API will build
>> - httpd-trunk + apr-util-1.7: old API and old+new API will build
>> - httpd-trunk + apr-util-1.7 + https://github.com/apache/httpd/pull/438 
>> : new API and old+new API will 
>> build
> 
> What about httpd 2.4.x and apt-util 1.7.x?

httpd v2.4.x is identical to httpd-trunk. Everything in httpd-trunk has been 
backported to v2.4, so it's all the same code. Replace httpd-trunk with 
httpd-2.4.x and you get the same matrix above.

I use this in production using apr-util v1.7 + httpd 2.4.63 at the moment. The 
end goal is I get full SASL support, specifically EXTERNAL over unix domain 
sockets, and it works great.

Regards,
Graham
--

Re: apr-util v1.7: request for more testing

[Eric Covener]

On Fri, Mar 21, 2025 at 9:37 AM Graham Leggett  wrote:
>
> On 21 Mar 2025, at 00:02, Eric Covener  wrote:
>
> >> Keen to get z/OS tested if anyone has access.
> >
> > I will try to  chip away at getting apr-trunk to building/running.
> >
> > We only use an old fork there with a very convoluted build.
>
> I applied for dev access to z/OS, I will need hand holding though.
>
> I've made sure that the Tivoli LDAP API is supportable in the new API, keen 
> to make sure it works as one of the supported APIs.

I put in a bunch of small workarounds to make progress, but currently
blocked on getting LDAP stubs to build so nothing is executing yet. We
never had DBD or anything else with stubs in our embedded APR/APU.This
platform has shared library oddities and we use a substitute libtool
(similar to build/jlibtool.c?).  I am trying to get it working for the
apr_ldap stub now.

>From a pure ldap.h POV there were a few breaks:

- Doesn't exist: LDAPAPIInfo (seems to be present on Tivoli though)
and LDAP_OPT_DESC (not present on Tivoli AFAICT)
- LDAP_OPT_ON/LDAP_OPT_OFF are ints, not already pointers to ints (I
just disabled for now, tivoli appears the same)
- Values for LDAP_OPT_REFHOPLIMIT/LDAP_OPT_PROTOCOL_VERSION needed a
(void*) cast (tivoli unknown, seems to be more about the compiler and
having the val be the address of an enum value so assumed n/a for
tivoli)

Unfortunately the people with real background in zOS related  to
apr/httpd are no longer with IBM / no longer active.

I will try to get my notes into better shape and share the quick
workarounds as well as a copy of the libtool substitute.

If you get access to a system, you probably want this package manager:
https://github.com/zopencommunity with at least git, bash, gmake,
autoconf, and m4.

If you build apr-trunk from git with the native compiler, you have to
avoid getting files tagged as UTF-8 (I switch to IBM-1047 rather than
ISO8859-1 as this is how we handle our bundled APR in our HTTPD fork):
https://github.com/zopencommunity/gitport?tab=readme-ov-file#encodings-and-zos-file-tags-ccsids

Re: apr-util v1.7: request for more testing

[Graham Leggett via dev]

On 21 Mar 2025, at 00:02, Eric Covener  wrote:

>> Keen to get z/OS tested if anyone has access.
> 
> I will try to  chip away at getting apr-trunk to building/running.
> 
> We only use an old fork there with a very convoluted build.

I applied for dev access to z/OS, I will need hand holding though.

I've made sure that the Tivoli LDAP API is supportable in the new API, keen to 
make sure it works as one of the supported APIs.

Regards,
Graham
--

Re: apr-util v1.7: request for more testing

[Graham Leggett via dev]

On 25 Mar 2025, at 14:03, Rainer Jung  wrote:

> I tried compiling httpd 2.4.63 against apr-util 1.7.x head. It fails during 
> compilation of the generated exports.c.
> 
> exports.c contains
> 
> ...
> #include "apr_ldap_common.h"
> #include "apr_ldap.h"
> #include "apr_ldap_init.h"
> #include "apr_ldap_option.h"
> #include "apr_ldap_rebind.h"
> #include "apr_ldap_url.h"
> ...
> 
> but apr_ldap.h must be included first. The order above comes from 
> server/export_files, which in turn is generated by server/Makefile. There the 
> list of header files is sorted using "sort".
> 
> With LANG=en_US.UTF-8 (as in my case) sort seems to make no distinction 
> between "." and "_", so "common.h" comes before "h" and the other files. With 
> LANG=X or POSIX, the order is the one we need. It seems we have to fix this.

Hmmm... a sort that isn't stable isn't repeatable.

Is the fix to add a LANG=POSIX in front of the sort?

> Another small problem: compiling apr-util 1.7.x with ldap is broken an SLES 
> 11 and RHEL 6. They use old compilers and do not allow (compatible) 
> redefinition of structs. So the compilation fails with:
> 
> /bin/bash /path/to/my/libtool --silent --mode=compile --tag=CC gcc ... -o 
> ldap/apr_ldap.lo -c /path/to/my/ldap/apr_ldap.c && touch ldap/apr_ldap.lo
> 
> /path/to/my/ldap/apr_ldap.c:91: error: redefinition of typedef 'apr_ldap_t'
> /path/to/my/include/apr_ldap_common.h:172: error: previous declaration of 
> 'apr_ldap_t' was here
> make[1]: *** [ldap/apr_ldap.lo] Error 1

I fixed this in r1924621, can you confirm for me?

Regards,
Graham
--

Re: apr-util v1.7: request for more testing

[Graham Leggett via dev]

On 24 Mar 2025, at 17:20, Eric Covener  wrote:

> Changed bits are fine on zOS (stub still not loading).
> 
> The use of LDAP_OPT_OFF/ON here is still a warning:
>>   void *refs = invalue->refs ? LDAP_OPT_ON : LDAP_OPT_OFF;
> 
> Due to:
> 
> $ grep LDAP_OPT_ON /usr/include/ldap.h
> #define LDAP_OPT_ON 0x01
> 
> WARNING CCN3196 ./ldap/apr_ldap.c:1081  Initialization between types
> "void*" and "int" is not allowed.
> 
> But I haven't gotten back to / paste the the dlsym issue in the stub
> so none of it has run.
> 
> In the older codebase, we only used LDAP_OPT_ON in SDK-specific code I
> think so there was no autoconf check.

Reading the docs at 
https://www.ibm.com/docs/en/zos/3.1.0?topic=routines-ldap-set-option-ldap-set-option-np
 it looks like this patch should work:

Index: ldap/apr_ldap.c
===
--- ldap/apr_ldap.c (revision 1924559)
+++ ldap/apr_ldap.c (working copy)
@@ -1055,7 +1055,7 @@
 break;
 
 case APR_LDAP_OPT_REFERRALS: {
-void *refs = invalue->refs ? LDAP_OPT_ON : LDAP_OPT_OFF;
+void *refs = invalue->refs ? (void *)LDAP_OPT_ON : (void 
*)LDAP_OPT_OFF;
 
 /* Setting this option is supported on at least TIVOLI_SDK and 
OpenLDAP.
  */


Seems the params are either zero or NULL, alternatively not-zero or not-NULL. 
As a result the cast gives this effect on all toolkits.

Regards,
Graham
--

Re: apr-util v1.7: request for more testing

[Rainer Jung]

Am 20.03.25 um 22:52 schrieb Graham Leggett via dev:

On 20 Mar 2025, at 16:12, Rainer Jung  wrote:


Am 20.03.25 um 16:34 schrieb Graham Leggett via dev:

On 20 Mar 2025, at 15:08, Graham Leggett  wrote:

...

To sum up:
- httpd-trunk + apr-trunk - old API and new API will not build by definition.
- httpd-trunk + apr-trunk + https://github.com/apache/httpd/pull/438: 
 new API and new API will build
- httpd-trunk + apr-util-1.7: old API and old+new API will build
- httpd-trunk + apr-util-1.7 + https://github.com/apache/httpd/pull/438 
: new API and old+new API will build


What about httpd 2.4.x and apt-util 1.7.x?


httpd v2.4.x is identical to httpd-trunk. Everything in httpd-trunk has been 
backported to v2.4, so it's all the same code. Replace httpd-trunk with 
httpd-2.4.x and you get the same matrix above.

I use this in production using apr-util v1.7 + httpd 2.4.63 at the moment. The 
end goal is I get full SASL support, specifically EXTERNAL over unix domain 
sockets, and it works great.


I tried compiling httpd 2.4.63 against apr-util 1.7.x head. It fails 
during compilation of the generated exports.c.


exports.c contains

...
#include "apr_ldap_common.h"
#include "apr_ldap.h"
#include "apr_ldap_init.h"
#include "apr_ldap_option.h"
#include "apr_ldap_rebind.h"
#include "apr_ldap_url.h"
...

but apr_ldap.h must be included first. The order above comes from 
server/export_files, which in turn is generated by server/Makefile. 
There the list of header files is sorted using "sort".


With LANG=en_US.UTF-8 (as in my case) sort seems to make no distinction 
between "." and "_", so "common.h" comes before "h" and the other files. 
With LANG=X or POSIX, the order is the one we need. It seems we have to 
fix this.



Another small problem: compiling apr-util 1.7.x with ldap is broken an 
SLES 11 and RHEL 6. They use old compilers and do not allow (compatible) 
redefinition of structs. So the compilation fails with:


/bin/bash /path/to/my/libtool --silent --mode=compile --tag=CC gcc ... 
-o ldap/apr_ldap.lo -c /path/to/my/ldap/apr_ldap.c && touch ldap/apr_ldap.lo


/path/to/my/ldap/apr_ldap.c:91: error: redefinition of typedef 'apr_ldap_t'
/path/to/my/include/apr_ldap_common.h:172: error: previous declaration 
of 'apr_ldap_t' was here

make[1]: *** [ldap/apr_ldap.lo] Error 1

Best regards,

Rainer

Re: apr-util v1.7: request for more testing

[Graham Leggett via dev]

On 21 Mar 2025, at 15:53, Ivan Zhakov  wrote:

> There some suspicious warnings during build on Windows x64 in apu-1.7.x:
> ldap\apr_ldap_option.c(336): warning C4311: 'type cast': pointer truncation 
> from 'void *' to 'ULONG'
> ldap\apr_ldap_option.c(345): warning C4311: 'type cast': pointer truncation 
> from 'void *' to 'ULONG'
> ldap\apr_ldap.c(375): warning C4133: 'function': incompatible types - from 
> 'apu_err_t **' to 'apr_ldap_err_t **'
> ldap\apr_ldap.c(594): warning C4311: 'type cast': pointer truncation from 
> 'void *' to 'ULONG'
> ldap\apr_ldap.c(603): warning C4311: 'type cast': pointer truncation from 
> 'void *' to 'ULONG'
> 
> The typecast warnings in ldap_set_option() look like a real bug. The attached 
> patch **should** fix it, but I don't have the environment to test LDAP.

This is an awesome catch.

I went digging for example Microsoft code to double check, and this fix makes 
sense. It's made no difference on COPR (it should not have) and GitHub actions 
on Windows are happy.

> It would be nice to have APR 1.7.5 released for proper APR-Util 1.7.x CMake 
> testing. See [1]. In this case after APR-Util 1.7.x release we can finally 
> get proper vcpkg ports for APR and APR-Util.
> 
> [1]: https://lists.apache.org/thread/l0v6k7b6xq85r3x2c3grd768y2lgthsc

Will definitely review a release.

Regards,
Graham
--

Re: apr-util v1.7: request for more testing

[Eric Covener]

>  case APR_LDAP_OPT_REFERRALS: {
>
> -void *refs = invalue->refs ? LDAP_OPT_ON : LDAP_OPT_OFF;
>
> +void *refs = invalue->refs ? (void *)LDAP_OPT_ON : (void 
> *)LDAP_OPT_OFF;

> Seems the params are either zero or NULL, alternatively not-zero or not-NULL. 
> As a result the cast gives this effect on all toolkits.

No warnings this way.

Re: apr-util v1.7: request for more testing

[Eric Covener]

Changed bits are fine on zOS (stub still not loading).

The use of LDAP_OPT_OFF/ON here is still a warning:
>void *refs = invalue->refs ? LDAP_OPT_ON : LDAP_OPT_OFF;

Due to:

$ grep LDAP_OPT_ON /usr/include/ldap.h
#define LDAP_OPT_ON 0x01

WARNING CCN3196 ./ldap/apr_ldap.c:1081  Initialization between types
"void*" and "int" is not allowed.

But I haven't gotten back to / paste the the dlsym issue in the stub
so none of it has run.

In the older codebase, we only used LDAP_OPT_ON in SDK-specific code I
think so there was no autoconf check.


On Mon, Mar 24, 2025 at 10:18 AM Graham Leggett  wrote:
>
> On 21 Mar 2025, at 22:09, Eric Covener  wrote:
>
> libtool port: https://github.com/covener/zlibtool
> patch attached to get apr-trunk compiling and linking, but ran out of
> time before getting the dlsym in th stub working.
> (./configure --prefix=$PWD/built  --with-expat=$HOME/expat/
> --with-ldap-include=/usr/include --with-ldap-lib=/usr/lib/GLDCLD64.x
> --with-ldap)
>
>
> I've updated the patch to detect the missing symbols generically, and return 
> APR_ENOTIMPL where unsupported.
>
> Can you confirm is this patch works for you? It currently builds fine across 
> COPR.
>
> Regards,
> Graham
> --
>
> Index: ldap/apr_ldap.c
>
> ===
>
> --- ldap/apr_ldap.c (revision 1924547)
>
> +++ ldap/apr_ldap.c (working copy)
>
> @@ -770,6 +770,7 @@
>
>
>
>  switch (option) {
>
>  case APR_LDAP_OPT_API_INFO: {
>
> +#if defined(LDAP_OPT_API_INFO)
>
>  LDAPAPIInfo info = { 0 };
>
>
>
>  info.ldapai_info_version = LDAP_API_INFO_VERSION;
>
> @@ -783,9 +784,15 @@
>
>  outvalue->info.vendor_version = info.ldapai_vendor_version;
>
>
>
>  break;
>
> -
>
> +#else
>
> +result->reason = "LDAP: API info not yet supported by APR on this "
>
> + "LDAP SDK";
>
> +result->rc = LDAP_UNWILLING_TO_PERFORM;
>
> +return APR_ENOTIMPL;
>
> +#endif
>
>  }
>
>  case APR_LDAP_OPT_API_FEATURE_INFO: {
>
> +#if defined(LDAP_OPT_API_FEATURE_INFO)
>
>  LDAPAPIFeatureInfo ldfi = { 0 };
>
>
>
>  ldfi.ldapaif_info_version = LDAP_FEATURE_INFO_VERSION;
>
> @@ -797,6 +804,12 @@
>
>
>
>  break;
>
>
>
> +#else
>
> +result->reason = "LDAP: API feature info not yet supported by APR on 
> this "
>
> + "LDAP SDK";
>
> +result->rc = LDAP_UNWILLING_TO_PERFORM;
>
> +return APR_ENOTIMPL;
>
> +#endif
>
>  }
>
>  case APR_LDAP_OPT_PROTOCOL_VERSION: {
>
>
>
> @@ -811,6 +824,7 @@
>
>  return APR_SUCCESS;
>
>  }
>
>  case APR_LDAP_OPT_DESC: {
>
> +#if defined(LDAP_OPT_DESC)
>
>
>
>  apr_status_t status = APR_SUCCESS;
>
>
>
> @@ -829,6 +843,12 @@
>
>  outvalue->socket = ldap->socket;
>
>
>
>  return status;
>
> +#else
>
> +result->reason = "LDAP: LDAP_OPT_DESC not yet supported by APR on 
> this "
>
> + "LDAP SDK";
>
> +result->rc = LDAP_UNWILLING_TO_PERFORM;
>
> +return APR_ENOTIMPL;
>
> +#endif
>
>  }
>
>  case APR_LDAP_OPT_URI: {
>
>  #if APR_HAS_OPENLDAP_LDAPSDK
>
> @@ -1035,7 +1055,7 @@
>
>  break;
>
>
>
>  case APR_LDAP_OPT_PROTOCOL_VERSION:
>
> -rc = ldap_set_option(ldap ? ldap->ld : NULL, 
> LDAP_OPT_PROTOCOL_VERSION, &invalue->pv);
>
> +rc = ldap_set_option(ldap ? ldap->ld : NULL, 
> LDAP_OPT_PROTOCOL_VERSION, (void*)&invalue->pv);
>
>  break;
>
>
>
>  case APR_LDAP_OPT_HANDLE:
>
> @@ -1054,9 +1074,10 @@
>
>  #endif
>
>
>
>  case APR_LDAP_OPT_DEREF:
>
> -rc = ldap_set_option(ldap ? ldap->ld : NULL, LDAP_OPT_DEREF, 
> &invalue->deref);
>
> +rc = ldap_set_option(ldap ? ldap->ld : NULL, LDAP_OPT_DEREF, 
> (void*)&invalue->deref);
>
>  break;
>
>
>
> +#if !APR_HAS_ZOS_LDAPSDK
>
>  case APR_LDAP_OPT_REFERRALS: {
>
>  void *refs = invalue->refs ? LDAP_OPT_ON : LDAP_OPT_OFF;
>
>
>
> @@ -1066,6 +1087,7 @@
>
>  break;
>
>
>
>  }
>
> +#endif
>
>  case APR_LDAP_OPT_REFHOPLIMIT:
>
>  #if defined(LDAP_OPT_REFERRAL_HOP_LIMIT)
>
>  /* Microsoft SDK defines LDAP_OPT_REFERRAL_HOP_LIMIT
>
> @@ -1074,7 +1096,7 @@
>
>  #elif defined(LDAP_OPT_REFHOPLIMIT)
>
>  /* Setting this option is supported on TIVOLI_SDK.
>
>   */
>
> -rc = ldap_set_option(ldap ? ldap->ld : NULL, LDAP_OPT_REFHOPLIMIT, 
> &invalue->refhoplimit);
>
> +rc = ldap_set_option(ldap ? ldap->ld : NULL, LDAP_OPT_REFHOPLIMIT, 
> (void*)&invalue->refhoplimit);
>
>  #else
>
>  /* If the LDAP_OPT_REFHOPLIMIT symbol is missing, assume that the
>
>   * particular LDAP library has a reasonable default. So far certain
>
>


-- 
Eric Covener
cove...@gmail.com

Re: apr-util v1.7: request for more testing

[Graham Leggett via dev]

On 21 Mar 2025, at 22:09, Eric Covener  wrote:

> libtool port: https://github.com/covener/zlibtool
> patch attached to get apr-trunk compiling and linking, but ran out of
> time before getting the dlsym in th stub working.
> (./configure --prefix=$PWD/built  --with-expat=$HOME/expat/
> --with-ldap-include=/usr/include --with-ldap-lib=/usr/lib/GLDCLD64.x
> --with-ldap)

I've updated the patch to detect the missing symbols generically, and return 
APR_ENOTIMPL where unsupported.

Can you confirm is this patch works for you? It currently builds fine across 
COPR.

Regards,
Graham
--

Index: ldap/apr_ldap.c
===
--- ldap/apr_ldap.c (revision 1924547)
+++ ldap/apr_ldap.c (working copy)
@@ -770,6 +770,7 @@
 
 switch (option) {
 case APR_LDAP_OPT_API_INFO: {
+#if defined(LDAP_OPT_API_INFO)
 LDAPAPIInfo info = { 0 };
 
 info.ldapai_info_version = LDAP_API_INFO_VERSION;
@@ -783,9 +784,15 @@
 outvalue->info.vendor_version = info.ldapai_vendor_version;
 
 break;
-
+#else
+result->reason = "LDAP: API info not yet supported by APR on this "
+ "LDAP SDK";
+result->rc = LDAP_UNWILLING_TO_PERFORM;
+return APR_ENOTIMPL;
+#endif
 }
 case APR_LDAP_OPT_API_FEATURE_INFO: {
+#if defined(LDAP_OPT_API_FEATURE_INFO)
 LDAPAPIFeatureInfo ldfi = { 0 };
 
 ldfi.ldapaif_info_version = LDAP_FEATURE_INFO_VERSION;
@@ -797,6 +804,12 @@
 
 break;
 
+#else
+result->reason = "LDAP: API feature info not yet supported by APR on 
this "
+ "LDAP SDK";
+result->rc = LDAP_UNWILLING_TO_PERFORM;
+return APR_ENOTIMPL;
+#endif
 }
 case APR_LDAP_OPT_PROTOCOL_VERSION: {
 
@@ -811,6 +824,7 @@
 return APR_SUCCESS;
 }
 case APR_LDAP_OPT_DESC: {
+#if defined(LDAP_OPT_DESC)
 
 apr_status_t status = APR_SUCCESS;
 
@@ -829,6 +843,12 @@
 outvalue->socket = ldap->socket;
 
 return status;
+#else
+result->reason = "LDAP: LDAP_OPT_DESC not yet supported by APR on this 
"
+ "LDAP SDK";
+result->rc = LDAP_UNWILLING_TO_PERFORM;
+return APR_ENOTIMPL;
+#endif
 }
 case APR_LDAP_OPT_URI: {
 #if APR_HAS_OPENLDAP_LDAPSDK
@@ -1035,7 +1055,7 @@
 break;
 
 case APR_LDAP_OPT_PROTOCOL_VERSION:
-rc = ldap_set_option(ldap ? ldap->ld : NULL, 
LDAP_OPT_PROTOCOL_VERSION, &invalue->pv);
+rc = ldap_set_option(ldap ? ldap->ld : NULL, 
LDAP_OPT_PROTOCOL_VERSION, (void*)&invalue->pv);
 break;
 
 case APR_LDAP_OPT_HANDLE:
@@ -1054,9 +1074,10 @@
 #endif
 
 case APR_LDAP_OPT_DEREF:
-rc = ldap_set_option(ldap ? ldap->ld : NULL, LDAP_OPT_DEREF, 
&invalue->deref);
+rc = ldap_set_option(ldap ? ldap->ld : NULL, LDAP_OPT_DEREF, 
(void*)&invalue->deref);
 break;
 
+#if !APR_HAS_ZOS_LDAPSDK
 case APR_LDAP_OPT_REFERRALS: {
 void *refs = invalue->refs ? LDAP_OPT_ON : LDAP_OPT_OFF;
 
@@ -1066,6 +1087,7 @@
 break;
 
 }
+#endif
 case APR_LDAP_OPT_REFHOPLIMIT:
 #if defined(LDAP_OPT_REFERRAL_HOP_LIMIT)
 /* Microsoft SDK defines LDAP_OPT_REFERRAL_HOP_LIMIT
@@ -1074,7 +1096,7 @@
 #elif defined(LDAP_OPT_REFHOPLIMIT)
 /* Setting this option is supported on TIVOLI_SDK.
  */
-rc = ldap_set_option(ldap ? ldap->ld : NULL, LDAP_OPT_REFHOPLIMIT, 
&invalue->refhoplimit);
+rc = ldap_set_option(ldap ? ldap->ld : NULL, LDAP_OPT_REFHOPLIMIT, 
(void*)&invalue->refhoplimit);
 #else
 /* If the LDAP_OPT_REFHOPLIMIT symbol is missing, assume that the
  * particular LDAP library has a reasonable default. So far certain

Re: apr-util v1.7: request for more testing

[Ivan Zhakov]

On Thu, 20 Mar 2025 at 14:20, Graham Leggett via dev 
wrote:

> Hi all,
>
> I have done a whole lot of testing of both apr v2.0 and apr-util v1.7, and
> cleaned up as much as I can find. The testing has largely been done on
> Linux machines (through our own CI, as well as Fedora COPR), MacOS, and
> Windows through the new cmake builds.
>
> Great!

There some suspicious warnings during build on Windows x64 in apu-1.7.x:
ldap\apr_ldap_option.c(336): warning C4311: 'type cast': pointer truncation
from 'void *' to 'ULONG'
ldap\apr_ldap_option.c(345): warning C4311: 'type cast': pointer truncation
from 'void *' to 'ULONG'
ldap\apr_ldap.c(375): warning C4133: 'function': incompatible types - from
'apu_err_t **' to 'apr_ldap_err_t **'
ldap\apr_ldap.c(594): warning C4311: 'type cast': pointer truncation from
'void *' to 'ULONG'
ldap\apr_ldap.c(603): warning C4311: 'type cast': pointer truncation from
'void *' to 'ULONG'

The typecast warnings in ldap_set_option() look like a real bug. The
attached patch **should** fix it, but I don't have the environment to test
LDAP.

It would be nice to have APR 1.7.5 released for proper APR-Util 1.7.x CMake
testing. See [1]. In this case after APR-Util 1.7.x release we can finally
get proper vcpkg ports for APR and APR-Util.

[1]: https://lists.apache.org/thread/l0v6k7b6xq85r3x2c3grd768y2lgthsc

-- 
Ivan Zhakov
Index: ldap/apr_ldap.c
===
--- ldap/apr_ldap.c (revision 1924512)
+++ ldap/apr_ldap.c (working copy)
@@ -591,8 +591,7 @@
 /* Microsoft SDK */
 #if APR_HAS_MICROSOFT_LDAPSDK
 if (tls == APR_LDAP_NONE) {
-ULONG ul = (ULONG) LDAP_OPT_OFF;
-result->rc = ldap_set_option(ldap, LDAP_OPT_SSL, &ul);
+result->rc = ldap_set_option(ldap, LDAP_OPT_SSL, LDAP_OPT_OFF);
 if (result->rc != LDAP_SUCCESS) {
 result->reason = "LDAP: an attempt to set LDAP_OPT_SSL off "
  "failed.";
@@ -600,8 +599,7 @@
 }
 }
 else if (tls == APR_LDAP_SSL) {
-ULONG ul = (ULONG) LDAP_OPT_ON;
-result->rc = ldap_set_option(ldap, LDAP_OPT_SSL, &ul);
+result->rc = ldap_set_option(ldap, LDAP_OPT_SSL, LDAP_OPT_ON);
 if (result->rc != LDAP_SUCCESS) {
 result->reason = "LDAP: an attempt to set LDAP_OPT_SSL on "
  "failed.";
Index: ldap/apr_ldap_option.c
===
--- ldap/apr_ldap_option.c  (revision 1924512)
+++ ldap/apr_ldap_option.c  (working copy)
@@ -333,8 +333,7 @@
 /* Microsoft SDK */
 #if APR_HAS_MICROSOFT_LDAPSDK
 if (tls == APR_LDAP_NONE) {
-ULONG ul = (ULONG) LDAP_OPT_OFF;
-result->rc = ldap_set_option(ldap, LDAP_OPT_SSL, &ul);
+result->rc = ldap_set_option(ldap, LDAP_OPT_SSL, LDAP_OPT_OFF);
 if (result->rc != LDAP_SUCCESS) {
 result->reason = "LDAP: an attempt to set LDAP_OPT_SSL off "
  "failed.";
@@ -342,8 +341,7 @@
 }
 }
 else if (tls == APR_LDAP_SSL) {
-ULONG ul = (ULONG) LDAP_OPT_ON;
-result->rc = ldap_set_option(ldap, LDAP_OPT_SSL, &ul);
+result->rc = ldap_set_option(ldap, LDAP_OPT_SSL, LDAP_OPT_ON);
 if (result->rc != LDAP_SUCCESS) {
 result->reason = "LDAP: an attempt to set LDAP_OPT_SSL on "
  "failed.";

Re: apr-util v1.7: request for more testing

[Rainer Jung]

Am 20.03.25 um 16:34 schrieb Graham Leggett via dev:

On 20 Mar 2025, at 15:08, Graham Leggett  wrote:

...

To sum up:

- httpd-trunk + apr-trunk - old API and new API will not build by 
definition.
- httpd-trunk + apr-trunk + https://github.com/apache/httpd/pull/438: 
 new API and new API will build

- httpd-trunk + apr-util-1.7: old API and old+new API will build
- httpd-trunk + apr-util-1.7 + https://github.com/apache/httpd/pull/438 
: new API and old+new API 
will build


What about httpd 2.4.x and apt-util 1.7.x?

Best regards,

Rainer

Re: apr-util v1.7: request for more testing

[Eric Covener]

On Fri, Mar 21, 2025 at 10:28 AM Eric Covener  wrote:
>
> On Fri, Mar 21, 2025 at 9:37 AM Graham Leggett  wrote:
> >
> > On 21 Mar 2025, at 00:02, Eric Covener  wrote:
> >
> > >> Keen to get z/OS tested if anyone has access.
> > >
> > > I will try to  chip away at getting apr-trunk to building/running.
> > >
> > > We only use an old fork there with a very convoluted build.
> >
> > I applied for dev access to z/OS, I will need hand holding though.
> >
> > I've made sure that the Tivoli LDAP API is supportable in the new API, keen 
> > to make sure it works as one of the supported APIs.
>
> I put in a bunch of small workarounds to make progress, but currently
> blocked on getting LDAP stubs to build so nothing is executing yet. We
> never had DBD or anything else with stubs in our embedded APR/APU.This
> platform has shared library oddities and we use a substitute libtool
> (similar to build/jlibtool.c?).  I am trying to get it working for the
> apr_ldap stub now.
>
> From a pure ldap.h POV there were a few breaks:
>
> - Doesn't exist: LDAPAPIInfo (seems to be present on Tivoli though)
> and LDAP_OPT_DESC (not present on Tivoli AFAICT)
> - LDAP_OPT_ON/LDAP_OPT_OFF are ints, not already pointers to ints (I
> just disabled for now, tivoli appears the same)
> - Values for LDAP_OPT_REFHOPLIMIT/LDAP_OPT_PROTOCOL_VERSION needed a
> (void*) cast (tivoli unknown, seems to be more about the compiler and
> having the val be the address of an enum value so assumed n/a for
> tivoli)
>
> Unfortunately the people with real background in zOS related  to
> apr/httpd are no longer with IBM / no longer active.
>
> I will try to get my notes into better shape and share the quick
> workarounds as well as a copy of the libtool substitute.
>
> If you get access to a system, you probably want this package manager:
> https://github.com/zopencommunity with at least git, bash, gmake,
> autoconf, and m4.
>
> If you build apr-trunk from git with the native compiler, you have to
> avoid getting files tagged as UTF-8 (I switch to IBM-1047 rather than
> ISO8859-1 as this is how we handle our bundled APR in our HTTPD fork):
> https://github.com/zopencommunity/gitport?tab=readme-ov-file#encodings-and-zos-file-tags-ccsids

libtool port: https://github.com/covener/zlibtool
patch attached to get apr-trunk compiling and linking, but ran out of
time before getting the dlsym in th stub working.
(./configure --prefix=$PWD/built  --with-expat=$HOME/expat/
--with-ldap-include=/usr/include --with-ldap-lib=/usr/lib/GLDCLD64.x
--with-ldap)

-- 
Eric Covener
cove...@gmail.com


ldap.diff
Description: Binary data

Re: apr-util v1.7: request for more testing

[Eric Covener]

On Thu, Mar 20, 2025 at 9:20 AM Graham Leggett via dev
 wrote:
>
> Hi all,
>
> I have done a whole lot of testing of both apr v2.0 and apr-util v1.7, and 
> cleaned up as much as I can find. The testing has largely been done on Linux 
> machines (through our own CI, as well as Fedora COPR), MacOS, and Windows 
> through the new cmake builds.
>
> I'd like to expand this beyond to machines I don't have access to. If people 
> have access to other hardware, would it be possible to test both builds?
>
> Keen to get z/OS tested if anyone has access.

I will try to  chip away at getting apr-trunk to building/running.

We only use an old fork there with a very convoluted build.

Re: apr-util v1.7: request for more testing

[Graham Leggett via dev]

On 20 Mar 2025, at 15:08, Graham Leggett  wrote:

> Ideally I would like some more up to date feedback, taking into account all 
> the changes up till now. Reading through the links, I recognise and have 
> fixed most of them, particularly with respect to the Windows build.

Further clarification is needed, I don't think my descriptions came out clearly.

Apr-trunk contains a brand new LDAP API that shares zero common code, and zero 
compatibility with, the old APR-util v1 API.

This means that httpd-trunk today (which depends on the APR-util v1 API), will 
not build with apr-trunk today. This is not a regression, because prior to this 
apr-trunk had no LDAP API at all, and so https-trunk didn't build by definition.

The following PR changes httpd-trunk to use the apr-trunk API: 
https://github.com/apache/httpd/pull/438

APR-util v1.7 contains both the old LDAP API, and the new apr-trunk API, at the 
same time, so that migration is possible.

This means that httpd-trunk today should be able to build with apr-util 1.7 
today.

To sum up:

- httpd-trunk + apr-trunk - old API and new API will not build by definition.
- httpd-trunk + apr-trunk + https://github.com/apache/httpd/pull/438: new API 
and new API will build
- httpd-trunk + apr-util-1.7: old API and old+new API will build
- httpd-trunk + apr-util-1.7 + https://github.com/apache/httpd/pull/438 
: new API and old+new API will build

Does this make sense?

Regards,
Graham
--

Re: apr-util v1.7: request for more testing

[Graham Leggett via dev]

On 20 Mar 2025, at 14:52, Rainer Jung  wrote:

> it would be nice if you could look at the mail threads "Current Status of APU 
> 1.7.x ldap / httpd" and "Re: svn commit: r1919997 [1/3] ..." both starting at 
> Jan 23rd, 2025.

Ideally I would like some more up to date feedback, taking into account all the 
changes up till now. Reading through the links, I recognise and have fixed most 
of them, particularly with respect to the Windows build.

I have tried to lay my hands on as wide an array of machine as possible, but am 
struggling with some of them. If I could get accounts on some of these machines 
that would help a lot.

Regards,
Graham
--

Re: apr-util v1.7: request for more testing

[Rainer Jung]

Hi Graham,

Am 20.03.25 um 14:19 schrieb Graham Leggett via dev:

Hi all,

I have done a whole lot of testing of both apr v2.0 and apr-util v1.7, and 
cleaned up as much as I can find. The testing has largely been done on Linux 
machines (through our own CI, as well as Fedora COPR), MacOS, and Windows 
through the new cmake builds.

I'd like to expand this beyond to machines I don't have access to. If people 
have access to other hardware, would it be possible to test both builds?

Keen to get z/OS tested if anyone has access.


it would be nice if you could look at the mail threads "Current Status 
of APU 1.7.x ldap / httpd" and "Re: svn commit: r1919997 [1/3] ..." both 
starting at Jan 23rd, 2025.


Best regards,

Rainer