python-ldap-dev — discussion among developers

compiling against OpenLDAP 2.0.11

[Jens V. <je...@di...>]

hi guys,

a couple days ago there were some posts indicating that python-ldap does 
indeed build against 2.0.11.

i just tried building a python-ldap head CVS checkout against 2.0.11 and 
it stops with the well-known...

<snip>
checking for library containing ber_free... -llber
checking for library containing ldap_open... no
checking for ldap_open... no
configure: error: Couldn't find LDAP library
</snip>

can anyone confirm what the status is vis-a-vis OpenLDAP 2.x (or just 2.0.
11)? the postings led me to believe that no extra patches were needed at 
this point. if they are, can someone point them out? :)

jens

Re: result timeout

[Michael <mi...@st...>]

David Leonard wrote:
> =

> On Tue, 12 Jun 2001, Michael Str=F6der typed thusly:
> =

> > The result() method of current CVS version does not return
> > (None,None) as mentioned on
> > http://python-ldap.sourceforge.net/doc/lib/node9.html if timeout
> > occured. Simply None is returned.
> =

> Which should be changed? The code or the documentation?

Rather the code.

> or should it raise a timeout exception instead?
> its not hard to fix... but what to do?

Returning (None,None) has the advantage of not breaking existing
code. Hmm, but most people are not really using all the feature of
the API.

Raising an exception seems the better design. But on the other hand
I think it costs more performance to raise and handle an exception
which could be a drawback when polling with timeout parameter set to
0.

Well, I'd suggest raising timeout exception but would like to hear
other opinions as well - especially regarding compatibility to
existing code.

Ciao, Michael.

Re: result timeout

[David L. <dav...@cs...>]

On Tue, 12 Jun 2001, Michael Str=F6der typed thusly:

> The result() method of current CVS version does not return
> (None,None) as mentioned on
> http://python-ldap.sourceforge.net/doc/lib/node9.html if timeout
> occured. Simply None is returned.

Which should be changed? The code or the documentation?
or should it raise a timeout exception instead?
its not hard to fix... but what to do?

--- LDAPObject.c        2001/06/03 08:11:19     1.10
+++ LDAPObject.c        2001/06/13 00:43:53
@@ -1235,8 +1235,7 @@

     if (res_type =3D=3D 0) {
        /* Timeout has occured */
-       Py_INCREF(Py_None);
-       return Py_None;
+       return Py_BuildValue("(OO)", Py_None, Py_None);
     }

     /* thanks to Konstantin Chuguev for this */


--- libldap.tex Wed May 16 11:33:00 2001
+++ /tmp/x      Wed Jun 13 10:44:50 2001
@@ -524,7 +524,7 @@
 the method will wait indefinitely for a response.
 The timeout can be expressed as a floating-point value, and
 a value of \constant{0} effects a poll.
-If a timeout does occur, the tuple \constant{(None,None)} is returned.
+If a timeout does occur, \constant{None} is returned.
 (This should really have been a \exception{TIMEOUT} exception!)

 The \method{result()} method returns a tuple of the form

--- LDAPObject.c        2001/06/03 08:11:19     1.10
+++ LDAPObject.c        2001/06/13 00:51:12
@@ -1235,8 +1235,7 @@

     if (res_type =3D=3D 0) {
        /* Timeout has occured */
-       Py_INCREF(Py_None);
-       return Py_None;
+       return PyErr_SetObject(errobjects[LDAP_TIMEOUT], Py_None);
     }

     /* thanks to Konstantin Chuguev for this */

--=20
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

The entire history of the world is the triumph of the heartless over
the mindless.  - Sir Humphrey Appleby, Yes Minister.

Re: ldapmodule.so

[David L. <dav...@cs...>]

On Tue, 12 Jun 2001, Isabelle Moullet typed thusly:
> >Try downloading a source code release (1.10alpha3 is okay) and building it
> >in the same environment you want to run it.

> I have in fact downloaded the source code release (1.10alpha3 ) and
> installed it on my platform (Solaris 8 machine) following the README
> instructions(configure, make, make install). Is there something I
> should change in the Makefile to make it run ?

maybe a patch like that below would help. because solaris might have
ldap_init_templates() but not ldap_name2template().

if all else fails, undefine HAVE_LDAP_INIT_TEMPLATES in config.h and
re-make all the .o files

d



Index: configure.in
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/configure.in,v
retrieving revision 1.14
diff -u -r1.14 configure.in
--- configure.in	2001/05/16 17:03:57	1.14
+++ configure.in	2001/06/12 13:17:49
@@ -207,7 +207,8 @@
 	AC_DEFINE(LDAP_TYPE_IS_OPAQUE)
 fi

-AC_CHECK_FUNCS(ldap_modrdn2_s ldap_modrdn2 ldap_init_templates)
+AC_CHECK_FUNCS(ldap_modrdn2_s ldap_modrdn2)
+AC_CHECK_FUNCS(ldap_init_templates ldap_name2template)
 AC_CHECK_HEADERS(disptmpl.h)

 dnl
Index: Modules/template.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/template.c,v
retrieving revision 1.9
diff -u -r1.9 template.c
--- Modules/template.c	2001/05/12 08:08:39	1.9
+++ Modules/template.c	2001/06/12 13:18:07
@@ -235,6 +235,7 @@
 	return ret;
 }

+#ifdef HAVE_LDAP_NAME2TEMPLATE
 /* retrieve a template by name */
 static PyObject *
 Templates_name2template(self, args)
@@ -257,6 +258,7 @@
 static char Templates_name2template_doc[] =
 "name2template(name) -> template\n"
 "Do stuff.";
+#endif /* HAVE_LDAP_NAME2TEMPLATE */

 /* retrieve a template by objectClass */
 static PyObject *
@@ -307,8 +309,10 @@
 "Do stuff.";

 static PyMethodDef Templates_methods[] = {
+#ifdef HAVE_LDAP_NAME2TEMPLATE
 	{ "name2template", (PyCFunction)Templates_name2template,
 	  METH_VARARGS, Templates_name2template_doc },
+#endif /* HAVE_LDAP_NAME2TEMPLATE */
 	{ "oc2template", (PyCFunction)Templates_oc2template,
 	  METH_VARARGS, Templates_oc2template_doc },
 	{ NULL, NULL }
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

The entire history of the world is the triumph of the heartless over
the mindless.  - Sir Humphrey Appleby, Yes Minister.

Re: ldapmodule.so

[David L. <dav...@cs...>]

Salut,

the .so file you downloaded was most likely compiled against a
LDAP C library (libldap.a) that is different to the one you have
installed.

Try downloading a source code release (1.10alpha3 is okay) and building it
in the same environment you want to run it.

I've cc'd other people on the python-ldap-dev list since there are people
there who actually use python-ldap and are more willing to maintain and
support it.

d

On Tue, 12 Jun 2001, Isabelle Moullet typed thusly:

> As I got no response from BSCW project team I ask you if you can help me.
> I installed the python-ldap module (_ldapmodule.so) in view to use it
> with BSCW. I followed the README instructions but was not able to
> make it work with BSCW. As soon as I try a connection with my BSCW
> server, I get the following message:
>
> Traceback (innermost last):
>    File "BSCW3/pyc15/bs_cgi.py", line 20, in service
>    File "BSCW3/pyc15/cl_request.py", line 900, in handle_rq
>    File "BSCW3/pyc15/cl_request.py", line 993, in handle_it
>    File "BSCW3/pyc15/op_login.py", line 35, in handle_POST
>    File "BSCW3/pyc15/cl_request.py", line 668, in set_user
>    File "../packages/ldap/src/bs_ldapregister.py", line 42, in check
>      import ldap, bs_ldap, config_ldap
>    File "/usr/local/lib/python1.5/site-packages/python-ldap/ldap.py",
> line 2, in ?
>      from _ldap import __version__
> ImportError: ld.so.1: /usr/local/bin/python: fatal: relocation error:
> file ../packages/ldap/src/_ldapmodule.so: symbol ldap_name2template:
> referenced symbol not found
> BSCW Release: 001025-1520
>
> Looking in more details in the library with the unix command "nm", I
> could indeed see that the symbol ldap_name2template is undefined.. Is
> there something wrong in my configuration ? Any known problem with
> the ldapmodule ? I downloaded it from
> http://python-ldap.sourceforge.net/ and got the file _ldapmodule.so
> .. Is that correct ?
>
> Thanks for your help..
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

The entire history of the world is the triumph of the heartless over
the mindless.  - Sir Humphrey Appleby, Yes Minister.

Re: python-ldap builds against OpenLDAP 2.0.11 but not 1.2.12

[<dir...@di...>]

Michael Ströder wrote,

> Are you sure you did not commit anything? The current CVS builds
> against OpenLDAP 2.0. Unfortunately this breaks some important code
> in web2ldap since I can't set options anymore.
> 
> Can we first make a release which definitely can be built against
> OpenLDAP 1.2.12? I have troubles building python-ldap from CVS
> against 1.2.12. configure fails on ldap_open check.
> 
> After making a cleanly working release there should be a CVS branch
> made instead of just silently dropping support for 1.2.x.

Please release more often ...
I still can't update the package for FreeBSD as neither patch
nor cvs compiles here.

kind regards Dirk

- Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany

Re: python-ldap builds against OpenLDAP 2.0.11 but not 1.2.12

[Michael <mi...@st...>]

David Leonard wrote:
> =

> On Thu, 7 Jun 2001, Michael Str=F6der typed thusly:
> =

> > did you drop the support for builing python-ldap against OpenLDAP
> > 1.2.x?
> =

> in my local tree, and for the future, yes.. but i havent committed =

> anything into cvs about that though..

Are you sure you did not commit anything? The current CVS builds
against OpenLDAP 2.0. Unfortunately this breaks some important code
in web2ldap since I can't set options anymore.

Can we first make a release which definitely can be built against
OpenLDAP 1.2.12? I have troubles building python-ldap from CVS
against 1.2.12. configure fails on ldap_open check.

After making a cleanly working release there should be a CVS branch
made instead of just silently dropping support for 1.2.x.

Ciao, Michael.

Re: python-ldap builds against OpenLDAP 2.0.11 but not 1.2.12

[David L. <dav...@cs...>]

On Thu, 7 Jun 2001, Michael Str=F6der typed thusly:

> did you drop the support for builing python-ldap against OpenLDAP
> 1.2.x?

in my local tree, and for the future, yes.. but i havent committed anything
into cvs about that though..

d
--=20
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

The entire history of the world is the triumph of the heartless over
the mindless.  - Sir Humphrey Appleby, Yes Minister.

python-ldap builds against OpenLDAP 2.0.11 but not 1.2.12

[Michael <mi...@st...>]

David,

did you drop the support for builing python-ldap against OpenLDAP
1.2.x?

Ciao, Michael.

Re: unknown error

[David L. <dav...@cs...>]

Um, the whole point of LDAP_TYPE_IS_OPAQUE is that ld_errno is just not there.
i.e. the C header files just don't mention ld_errno, and we can't guess
where it is.

However, I recall that there are other (non-standard) APIs to get to
the error code.. something like ldap_get_error(LDAP *) which we could use.


On Wed, 6 Jun 2001, David Margrave typed thusly:

>
>     self.ldapconn.modify_s(self.dn, modlist)
> ldap.LDAPError: unknown error (C API does not expose error)
>
> This was from the latest packaged release (1.10a3 i think)
>
> Maybe we could make the exception for unknown errors include the numeric
> error code:
>
> #ifdef LDAP_TYPE_IS_OPAQUE
>         else {
>                 PyErr_SetString(LDAPexception_class,
>                         "unknown error (C API does not expose error
> %d)", l->ld_errno);
>
>                 return NULL;
>         }
> #else
>
> My $.02

-- 
David Leonard                           Dav...@ds...
CRC For Distributed Systems Technology  Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

EERROR - Erroneous error. Nothing wrong.

Re: Bug in 3 day old commit of LDAPObject.c?

[David L. <dav...@cs...>]

On Wed, 6 Jun 2001, Konstantin Chuguev typed thusly:

> It looks like the last CVS commit for LDAPObject.c (1.9 -> 1.10) has a
> bug. It should be changed this way:
> PY_XDECREF -> Py_XDECREF
> PY_INCREF -> Py_INCREF

revision 1.11
date: 2001/06/06 23:40:04;  author: leonard;  state: Exp;  lines: +7 -7
PY->Py. Thanks, Konstantin.

-- 
David Leonard                           Dav...@ds...
CRC For Distributed Systems Technology  Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

EERROR - Erroneous error. Nothing wrong.

Building current CVS version

[Michael <mi...@st...>]

HI!

Was there a change in the configure script? Does the autoconf method
still work?

Ciao, Michael.

unknown error

[David M. <da...@es...>]

    self.ldapconn.modify_s(self.dn, modlist)
ldap.LDAPError: unknown error (C API does not expose error)

This was from the latest packaged release (1.10a3 i think)

Maybe we could make the exception for unknown errors include the numeric
error code:

#ifdef LDAP_TYPE_IS_OPAQUE
        else {
                PyErr_SetString(LDAPexception_class,
                        "unknown error (C API does not expose error  
%d)", l->ld_errno);

                return NULL;
        }
#else

My $.02

Dave

cvs-server

[Sascha G. <sas...@op...>]

Hi !

While trying to get cvs-nserver running for a while now, I ran out of time.
(Looks like a peace of software which could be LDAP'ed.)
I'll be nearly offline until 25.6. . So could you please set up an 
cvs-server for swig-ldap (or whatever you like to call it) and give me a rsync/ssh or cvsupd - access, so the repository is mirrored to keep our work
alive even if some crashes might possibly happen ?

Thanx! Have fun!

Sascha



-- 
/* Yeah  */

Bug in 3 day old commit of LDAPObject.c?

[Konstantin C. <Kon...@da...>]

Hi,

It looks like the last CVS commit for LDAPObject.c (1.9 -> 1.10) has a
bug. It should be changed this way:
PY_XDECREF -> Py_XDECREF
PY_INCREF -> Py_INCREF

I'm not quite sure, but at least Python-2.1c2 has the right hand format
macros in its installed header files, not those introduced in the
commit. Maybe it worked fine in previous versions of Python?

Regards,
    Konstantin.

--
          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net

Re: Using set_rebind_proc(func) with a bound method

[David L. <dav...@cs...>]

Actually, I just realised that rebind_callback is incompatible with
multiple LDAP objects.

when rebind_callback() is called, it should look up the LDAP object
based on LDAP*ld, and not use a global var rebind_callback_ld (although
it does check that they're related)..

unless there's a nice part of the LDAP structure I can stick a backreference
to the python LDAPObject in, this could be done by having a global hash
(dictionary) of LDAP pointers to LDAPObjects...

has anyone experienced problems with multiple LDAP objects and rebinding?

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

The entire history of the world is the triumph of the heartless over
the mindless.  - Sir Humphrey Appleby, Yes Minister.

Re: Using set_rebind_proc(func) with a bound method

[David L. <dav...@cs...>]

On Tue, 5 Jun 2001, f.g...@fe... typed thusly:

> the problem is to check whether a callable object is either a function object
> or a *bound* method object.

just callable will do for now.

passing an unbound method will still result in a runtime error when a rebind
is needed... which I think is fine, since we can't completely check for
all type errors there - we could end up falsly prohibiting or falsely
allowing cases that we never thought of.

good testing is still required, ie do coverage testing/analysis and
find your type mistakes that way.

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

I put my chin on my knee, and looked for flaws in the soft grain of my
beige plastic monitor casing. - Julian Assange

Re: Using set_rebind_proc(func) with a bound method

[<f.g...@fe...>]

Hi,

the problem is to check whether a callable object is either a function object
or a *bound* method object.

>> -    if ( PyFunction_Check(func) ) {
>> +    if ( PyCallable_Check(func) ) {

Maybe its better to check

+    if ( PyCallable_Check(func) ) {
-    if ( PyFunction_Check(func) || (PyCFunction_Check(func) && PyCFunction_GET_SELF(func)) ) {


I havn't tested it and, again, I don't know whether it works on older Python versions
before 2.1.


Franz

Re: Minor bug in ldif.py

[Michael <mi...@st...>]

David Leonard wrote:
> 
> On Thu, 31 May 2001, Roger Moore typed thusly:
> 
> > I just noticed a slight bug in ldif.py to do with the deletion of the
> > object class list. The problem is that if you name the attribute
> > 'objectClass' then the first attrs.remove() statement generates an
> > exception and the second statement is not reached.
> > [..]
> i have committed a different fix.

Since the whole object class thingy was just for writing the
objectClass lines at the beginning of an entry I completely removed
it. It causes nothing but grief...

BTW: I made more modifications (__doc__ strings, more readable code,
etc.).

Ciao, Michael.

Re: Minor bug in ldif.py

[David L. <dav...@cs...>]

On Thu, 31 May 2001, Roger Moore typed thusly:

> I just noticed a slight bug in ldif.py to do with the deletion of the
> object class list. The problem is that if you name the attribute
> 'objectClass' then the first attrs.remove() statement generates an
> exception and the second statement is not reached. To fix this you can
> check for the key first. I've attached the patch to this email.
>
> As a very quick work around call the attribute 'objectclass'.

i have committed a different fix.
michael, you should check that this is right.

d

----------------------------
revision 1.3
date: 2001/06/04 03:05:26;  author: leonard;  state: Exp;  lines: +6 -0
add RCS tag
fix bug found by Roger Moore <rw...@fn...> where objectclass
attributes weren't always removed

Index: ldif.py
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Lib/ldif.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ldif.py	2001/05/07 17:25:42	1.2
+++ ldif.py	2001/06/04 03:05:26	1.3
@@ -1,3 +1,6 @@
+# python
+# $Id: ldif.py,v 1.3 2001/06/04 03:05:26 leonard Exp $
+
 """
 ldif.py - Various routines for handling LDIF data

@@ -81,6 +84,9 @@
   attrs = entry.keys()[:]
   try:
     attrs.remove('objectclass')
+  except ValueError:
+    pass
+  try:
     attrs.remove('objectClass')
   except ValueError:
     pass

-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

I put my chin on my knee, and looked for flaws in the soft grain of my
beige plastic monitor casing. - Julian Assange

Re: Using set_rebind_proc(func) with a bound method

[David L. <dav...@cs...>]

On Fri, 1 Jun 2001, f.g...@fe... typed thusly:

> But there is no reason why this "callback" should only work
> with "normal" functions in Python.

> -    if ( PyFunction_Check(func) ) {
> +    if ( PyCallable_Check(func) ) {
>
> -    PyErr_SetString( PyExc_TypeError, "expected function or None" );
> +    PyErr_SetString( PyExc_TypeError, "expected function, bound method or None" );


you are absoluetly correct
I will add this patch

> +        Py_XDECREF(rebind_callback_func);
> +        Py_INCREF(func);
> +        Py_XDECREF(rebind_callback_func);

and this one after i look at it more carefully..

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

I put my chin on my knee, and looked for flaws in the soft grain of my
beige plastic monitor casing. - Julian Assange

Using set_rebind_proc(func) with a bound method

[<f.g...@fe...>]

Hi,

currently I'm playing with python-ldap-1.10a3 on WinNT with
ActivePython 2.1.0-210b.

When dealing with LDAP referrals I tried to pass a
bound method object to set_rebind_proc, but it failed with the
exception "expected function or None".

But there is no reason why this "callback" should only work
with "normal" functions in Python.

So I patched the sources in file LDAPObject.c and changed the
function "l_ldap_set_rebind_proc":
Now the very specific check "PyFunction_Check(func)" is replaced
by "PyCallable_Check(func)". Passing bound methods now work.

I dont know whether this also works for older versions of Python
(and there is no check whether func is a unbound method object, but
here is the diff:



@@ -595,15 +595,18 @@
          ldap_set_rebind_proc( self->ldap, NULL, 0);
 #else
          ldap_set_rebind_proc( self->ldap, NULL );
 #endif
+        Py_XDECREF(rebind_callback_func);
     rebind_callback_func = NULL;
     rebind_callback_ld = NULL;
     Py_INCREF(Py_None);
     return Py_None;
     }

-    if ( PyFunction_Check(func) ) {
+    if ( PyCallable_Check(func) ) {
+        Py_XDECREF(rebind_callback_func);
+        Py_INCREF(func);
     rebind_callback_func = func;
     rebind_callback_ld = self;
 #ifdef LDAP_SET_REBIND_PROC_3ARGS
         ldap_set_rebind_proc( self->ldap, rebind_callback, 0);
@@ -613,9 +616,9 @@
     Py_INCREF(Py_None);
     return Py_None;
     }

-    PyErr_SetString( PyExc_TypeError, "expected function or None" );
+    PyErr_SetString( PyExc_TypeError, "expected function, bound method or None" );
     return NULL;
 }

 static char doc_set_rebind_proc[] =


Regards,
Franz

Minor bug in ldif.py

[Roger M. <rw...@fn...>]

Hi,

I just noticed a slight bug in ldif.py to do with the deletion of the
object class list. The problem is that if you name the attribute
'objectClass' then the first attrs.remove() statement generates an
exception and the second statement is not reached. To fix this you can
check for the key first. I've attached the patch to this email.

As a very quick work around call the attribute 'objectclass'.

Roger

Re: latest ldap.i UPDATE!

[Joe L. <jl...@op...>]

the attrs could be a problem. It may be one area of the mozilla API that =
I
didn't "expose" via SWIG.

Any comments Sascha?

I've simply used Sascha's makefile and the like so far, but the tests and
such will definitely need to be altered to confirm the ldap and its v3
extensions are working. Its a work in progress, and my without a network
:(. I'll try and put together some tests. Michael, if you have any
specific tests that you'd like to make sure they work, simply send them m=
y
way and I'll try and put them into the test suite. The current test suite
from Sascha expects openldap 1.x and its config/schema style.

On Wed, 30 May 2001, Michael Str=F6der wrote:

> Joe Little wrote:
> >
> > My only concern is your libraries. do an ldd on the ldapcmodule (ther=
e is
> > also the lbermodule.so). Make sure it sees the same ldap libraries yo=
u
> > built it with.
>
> Off course I already did this every time. Seemed ok to me:
>
> > ldd ldapcmodule.so
>         /lib/libNoVersion.so.1 =3D> /lib/libNoVersion.so.1
> (0x40015000)
>         libldap50.so =3D>
> /home/michael/src/ldapcsdk50/lib/libldap50.so (0x40017000)
>         libc.so.6 =3D> /lib/libc.so.6 (0x40047000)
>         /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
> > ldd lbermodule.so
>         /lib/libNoVersion.so.1 =3D> /lib/libNoVersion.so.1
> (0x4000a000)
>         libldap50.so =3D>
> /home/michael/src/ldapcsdk50/lib/libldap50.so (0x4000c000)
>         libc.so.6 =3D> /lib/libc.so.6 (0x4003c000)
>         /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
>
> > I'd then use the test ldapsearch in Sacha's test directory (with the
> > aforementioned changed in ldap.open instead of ldap.LDAP for opening =
a
> > connection.
>
> This did not work. I took a look at the source to figure out how it
> works and tried to track things down by typing the actions manually.
>
> Now please tell me what I did wrong in this transcript? It uses
> ldapc.open() to make the connection. That's definitely not problem.
> Maybe something's fishy with building "attrs"?
>
> Python 2.1 (#8, Apr 20 2001, 19:22:23)
> [GCC 2.95.2 19991024 (release)] on linux2
> Type "copyright", "credits" or "license" for more information.
> >>> import ldapc
> >>> attrs=3Dldapc.string_array(1)
> >>> ldapc.string_set(attrs,0,'objectClass')
> 'objectClass'
> >>> l=3Dldapc.open('localhost',389)
> >>> resPtr=3Dldapc.makeLDAPMessagePtrPtr()
> >>> status=3Dldapc.search_s(l,'O=3DMICHAELS',ldapc.SCOPE_BASE,
> '(objectClass=3D*)',attrs,0,resPtr)
> Segmentation fault
>
> Am I doing something wrong?
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: latest ldap.i UPDATE!

[Michael <mi...@st...>]

Joe Little wrote:
> 
> My only concern is your libraries. do an ldd on the ldapcmodule (there is
> also the lbermodule.so). Make sure it sees the same ldap libraries you
> built it with.

Off course I already did this every time. Seemed ok to me:

> ldd ldapcmodule.so 
        /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1
(0x40015000)
        libldap50.so =>
/home/michael/src/ldapcsdk50/lib/libldap50.so (0x40017000)
        libc.so.6 => /lib/libc.so.6 (0x40047000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> ldd lbermodule.so 
        /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1
(0x4000a000)
        libldap50.so =>
/home/michael/src/ldapcsdk50/lib/libldap50.so (0x4000c000)
        libc.so.6 => /lib/libc.so.6 (0x4003c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

> I'd then use the test ldapsearch in Sacha's test directory (with the
> aforementioned changed in ldap.open instead of ldap.LDAP for opening a
> connection.

This did not work. I took a look at the source to figure out how it
works and tried to track things down by typing the actions manually.

Now please tell me what I did wrong in this transcript? It uses
ldapc.open() to make the connection. That's definitely not problem.
Maybe something's fishy with building "attrs"?

Python 2.1 (#8, Apr 20 2001, 19:22:23)
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import ldapc
>>> attrs=ldapc.string_array(1)
>>> ldapc.string_set(attrs,0,'objectClass')
'objectClass'
>>> l=ldapc.open('localhost',389)
>>> resPtr=ldapc.makeLDAPMessagePtrPtr()
>>> status=ldapc.search_s(l,'O=MICHAELS',ldapc.SCOPE_BASE,
'(objectClass=*)',attrs,0,resPtr)
Segmentation fault

Am I doing something wrong?

Ciao, Michael.