Re: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl (pyldap: message 1 of 20)

[<pyl...@ne...>]

Michael,

I will try as you suggested and will compile the current versions of
openldap, python-ldap, cyrus-sasl, and openssl without any patches and
default options. I'll let you know how that turns out.

To respond to your point that you don't know what build options are
used, or what patches applied to binary distributions, here is what
the spec files I used to build openldap and python-ldap contained:
python-ldap only had one patch applied to it. I'll paste the patch
below, but the patch isn't the problem. I recompiled the python-ldap
RPM without any of the patches and ran into the same encoding error.

The packages was configured and built using the following two commands:
setup.py build
setup.py install --skip-build --root $RPM_BUILD_ROOT
($RPM_BUILD_ROOT being /var/tmp/python-ldap-2.3.5-root )

python-ldap-2.2.0-dirs.patch:
--- python-ldap-2.3.5/setup.cfg.dirs    2008-07-06 11:04:13.000000000 -0400
+++ python-ldap-2.3.5/setup.cfg 2008-09-03 13:45:20.000000000 -0400
@@ -2,8 +2,7 @@
 extra_objects =
 extra_compile_args =
 libs = ldap_r lber sasl2 ssl crypto
-library_dirs = /usr/local/openldap-2.3/lib
-include_dirs = /usr/local/openldap-2.3/include /usr/include/sasl
+include_dirs = /usr/include/sasl

OpenLDAP was built with considerably more patches and the build
process is extremely involved.
The following flags are used in building:
CFLAGS=" -D_REENTRANT -fPIC -D_GNU_SOURCE"

The OpenLDAP package RPM builds its own version of BerkeleyDB which it
builds like so:
configure -C \
    --with-pic \
    --disable-static \
    --enable-shared \
    --with-uniquename=_openldap_slapd_46 \
    --prefix=${dbdir} \
    --includedir=${dbdir}/include \
    --libdir=${dbdir}/%{_lib}${subdir:+/${subdir}}

make %{_smp_mflags} libdb_base=libslapd_db libso_base=libslapd_db
make install libdb_base=libslapd_db libso_base=libslapd_db strip="false"

OpenLDAP is configured and made with the following flags:
configure \
    --with-threads=posix \
    --enable-local --enable-rlookups \
    --with-tls \
    --with-cyrus-sasl \
    --enable-wrappers \
    --enable-passwd \
    --enable-cleartext \
    --enable-crypt \
    --enable-spasswd \
    --enable-lmpasswd \
    --enable-modules \
    --disable-sql \
    --libexecdir=%{_libdir} \
    $@
make %{_smp_mflags} LIBTOOL="$libtool"

The openldap clients are build using:
build \
    --disable-slapd \
    --enable-shared \
    --enable-dynamic \
    --enable-static \
    --without-kerberos \
    --with-pic



If there's any information you need to figure out what's going, let me
know and I'll be happy to grab it for you.

Dominic

On Thu, Mar 5, 2009 at 6:22 AM, Michael Ströder - mi...@st...
<+pyldap+dlobue+63e3ab027f.michael#str...@sp...>
wrote:
> pyl...@ne... wrote:
>>
>> I've run into the same problem as Joel on basically an identical setup
>> - CentOS 5.2, openldap 2.3.27-8.el5_2.4, python 2.4.3-21.el5,
>> python-ldap 2.2.0-2.1. This of course being on a 64 bit release of
>> CentOS.
>>
>> I did as you suggested and updated openldap to 2.4.12-1, and
>> python-ldap to 2.3.5-1, but I still received the exact same error.
>
> The problem with using binary packages is that I never know whether
> patches were applied by the distributor and which build parameters were
> used.
>
> Also note there's python-ldap with some minor build fixes and OpenLDAP
> 2.4.15 with numerous fixes to libldap. OpenLDAP developers will likely
> not give support with this issue if the problem cannot be reproduced
> with recent code.
>
>> Because you mentioned that you had never tested python-ldap on a 64
>> bit machine, I duplicated my setup in a VirtualBox VM only using a
>> i686 release of CentOS rather than x64.
>>
>> I ran my python program using the old versions of software ( openldap
>> 2.3.27-8.el5_2.4, python 2.4.3-21.el5, python-ldap 2.2.0-2) and it ran
>> without any problems whatsoever.
>
> Thanks for testing this.
>
>> Any suggestions on how to fix this?
>
> At the moment I have no idea how to proceed. I'd suggest to build from
> source. Not sure about compiler woes on that platform. E.g. try turning
> off optimization (with option -O0) when building from source.
>
> Ciao, Michael.
>