python-ldap-dev — discussion among developers

RE: Re: Internationalization patch, i18n, iconv, ...

[<js...@ne...>]

The iconv is part of glibc 2.2.2 and above, so iconv.h should be in any recent LINUX system if the C developement environment is configured. If older than glic 2.2.2, you might have to install the iconvlib seperately.

I did try to use PyString_(De/En)code, but it is not very well suited to openldap type of applications, especially if dn has mixed ascii and utf8 encodings.  But I will be happy if someone can prove I am wrong. 

Thanks.
J.


David Leonard <dav...@it...> wrote:

>
>On Sat, 13 Oct 2001, js...@ne... typed thusly:
>> I just worked out the python-ldap so that it will convert the
>> local charactors to utf8 or vice versa according to the user locale
>> setup.   This is done because OpenLdap currently only support utf8,
>> so  one has to make the  translation.   I tested on zh_CN.GB2312
>> (simplified Chinese), and it worked.  By no means it is a complete
>> test, but it is a good start, and it worked for me.  The patch was
>> generated against the CVS tree check out yesterday, so it is pretty
>> recent.
>> Here is the patch in the attachment.
>
>hi
>
>sorry i have been unable to respond to you - i had marked your
>message important but have been busy of late. :(
>
>i'm glad you send it to the list, because it will stand a better chance
>of being reviewed there.. a better chance than just sitting in my mailbox.
>
>here are my comments from a quick perusal of the diff
>
>... the diff is reversed. (took me a moment to figure out what was
>going on there!.. the order is 'diff <old> <new>')
>
>... you're relying on an iconv.h header file, which isn't on every
>system. (especially mine)
>
>.. I think instead to use PyString_Decode() and PyString_Encode()..
>that way you get python unicode string objects.
>
>i'm not an expert on these things, but here is a cut and paste from
>a python header file:
>
>/* Create a string object by decoding the encoded string s of the
>   given size. */
>
>extern DL_IMPORT(PyObject*) PyString_Decode(
>    const char *s,              /* encoded string */
>    int size,                   /* size of buffer */
>    const char *encoding,       /* encoding */
>    const char *errors          /* error handling */
>    );
>
>/* Encodes a char buffer of the given size and returns a
>   Python string object. */
>
>extern DL_IMPORT(PyObject*) PyString_Encode(
>    const char *s,              /* string char buffer */
>    int size,                   /* number of chars to encode */
>    const char *encoding,       /* encoding */
>    const char *errors          /* error handling */
>    );
>
>
>d
>
>-- 
>David Leonard                           Dav...@it...
>Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
>The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
>QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8
>
>Make sure that you have enough free memory in your temp directory.
>    - Sun StarOffice README
>
>
>


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Re: patch for Internationalization support (iconv)

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

Steffen Ries wrote:
> 
> js...@ne... writes:
> 
> > I just worked out the python-ldap so that it will convert the local
> > characters to utf8 or vice versa according to the user locale setup.
> > This is done because OpenLdap currently only support utf8, one has
> > to make the translation mannually getting in or out of openldap.
> 
> I would be careful with this patch.

Me too.

> It looks to me that you are converting *every* ldap attribute from the
> current locale encoding to UTF-8 (and vice versa). This takes care of
> the most common attributes, but it affects binary attributes as well,
> which it shouldn't.

Exactly. Without knowing the schema (syntax of attribute here) used
on the server a LDAP application should not simply assume UTF-8.
Also a really compliant application should look at the LDAP version
in use. LDAPv2 assumes T.61.

> IMHO a better approach would be to allow Python Unicode strings as
> well as regular strings for writing attributes, then encode unicode
> strings to UTF-8.

The application has to know the schema and therefore the application
is responsible for encoding before passing strings to python-ldap.
python-ldap is too low-level for that. I would even disallow passing
Unicode strings to python-ldap.

> For reading from LDAP, I'm not sure what the best approach would
> be. E.g. if the attribute type syntax is "Directory String", create a
> unicode string, otherwise create a literal string. But how do you know
> the attribute syntax?

Again: python-ldap is too low-level for that. Don't mess with
different string types! And rethink why default encoding in Python's
Unicode support is ASCII.

> Maybe it is best to leave the attributes as they
> are and leave the encoding to the user...

Definitely yes!

Ciao, Michael.

Re: patch for Internationalization support (iconv)

[Steffen R. <ste...@sy...>]

js...@ne... writes:

> I have sent to Leonard the patch, but did not get any indication of
> its being received, so here I send the patch again, see if it is
> useful to other people.
> 
> I just worked out the python-ldap so that it will convert the local
> characters to utf8 or vice versa according to the user locale setup.
> This is done because OpenLdap currently only support utf8, one has
> to make the translation mannually getting in or out of openldap.  I
> tested on zh_CN.GB2312 (simplified Chinese), and it worked.  By no
> means it is a complete test, but it is a good start, and it worked
> for me.  The patch was generated against the CVS tree check out
> yesterday, so it is pretty recent.

I would be careful with this patch.

It looks to me that you are converting *every* ldap attribute from the
current locale encoding to UTF-8 (and vice versa). This takes care of
the most common attributes, but it affects binary attributes as well,
which it shouldn't.

IMHO a better approach would be to allow Python Unicode strings as
well as regular strings for writing attributes, then encode unicode
strings to UTF-8.

For reading from LDAP, I'm not sure what the best approach would
be. E.g. if the attribute type syntax is "Directory String", create a
unicode string, otherwise create a literal string. But how do you know
the attribute syntax? Maybe it is best to leave the attributes as they
are and leave the encoding to the user...

just my 0.02$

/steffen
-- 
ste...@sy...	<> Gravity is a myth -- the Earth sucks!

Re: Internationalization patch, i18n, iconv, ...

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

On Sat, 13 Oct 2001, js...@ne... typed thusly:
> I just worked out the python-ldap so that it will convert the
> local charactors to utf8 or vice versa according to the user locale
> setup.   This is done because OpenLdap currently only support utf8,
> so  one has to make the  translation.   I tested on zh_CN.GB2312
> (simplified Chinese), and it worked.  By no means it is a complete
> test, but it is a good start, and it worked for me.  The patch was
> generated against the CVS tree check out yesterday, so it is pretty
> recent.
> Here is the patch in the attachment.

hi

sorry i have been unable to respond to you - i had marked your
message important but have been busy of late. :(

i'm glad you send it to the list, because it will stand a better chance
of being reviewed there.. a better chance than just sitting in my mailbox.

here are my comments from a quick perusal of the diff

... the diff is reversed. (took me a moment to figure out what was
going on there!.. the order is 'diff <old> <new>')

... you're relying on an iconv.h header file, which isn't on every
system. (especially mine)

.. I think instead to use PyString_Decode() and PyString_Encode()..
that way you get python unicode string objects.

i'm not an expert on these things, but here is a cut and paste from
a python header file:

/* Create a string object by decoding the encoded string s of the
   given size. */

extern DL_IMPORT(PyObject*) PyString_Decode(
    const char *s,              /* encoded string */
    int size,                   /* size of buffer */
    const char *encoding,       /* encoding */
    const char *errors          /* error handling */
    );

/* Encodes a char buffer of the given size and returns a
   Python string object. */

extern DL_IMPORT(PyObject*) PyString_Encode(
    const char *s,              /* string char buffer */
    int size,                   /* number of chars to encode */
    const char *encoding,       /* encoding */
    const char *errors          /* error handling */
    );


d

-- 
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Make sure that you have enough free memory in your temp directory.
	- Sun StarOffice README

patch for Internationalization support (iconv)

[<js...@ne...>]

I have sent to Leonard  the patch, but did not get any indication of its being received, so here I send the patch again, see if it is useful to other people.

 I just worked out the python-ldap so that it will convert the local characters to utf8 or vice versa according to the user locale setup.   This is done because OpenLdap currently only support utf8, one has to make the  translation mannually getting in or out of openldap.   I tested on zh_CN.GB2312 (simplified Chinese), and it worked.  By no means it is a complete test, but it is a good start, and it worked for me.  The patch was generated against the CVS tree check out yesterday, so it is pretty recent.
Here is the patch in the attachment.


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Re: _ldap problem and current resolution. -- found api change

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

Joe Little wrote:
> 
> please do commit... the effort to get current CS to work with Steffen's
> patches has been problematic on my end. I'd like there to be concensus
> (ie CVS committed) on what is the ideal 2.x version. I also think that
> the version number should be officially increased to 1.11alpha or
> whatever.

The version number symbol is already 1.11 for the OpenLDAP 1.2.x
branch. It was decided ages ago that the OpenLDAP 2 based branch
should get version numbers 2.x.

Since we have a tagged CVS archive for the OpenLDAP 1.2.x branch
(label OPENLDAP_1_BRANCH) I see no problem with Konstantin commiting
his work now.

Ciao, Michael.

Re: _ldap problem and current resolution. -- found api change

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

please do commit... the effort to get current CS to work with Steffen's=20=

patches has been problematic on my end. I'd like there to be concensus=20=

(ie CVS committed) on what is the ideal 2.x version. I also think that=20=

the version number should be officially increased to 1.11alpha or=20
whatever.

On Wednesday, October 3, 2001, at 02:03 AM, Konstantin Chuguev wrote:

> Hi All,
>
> A small update on what I'm doing:
> I have merged Steffen Ries's and my patches and built python-ldap with
> OpenLDAP-2.0.15. I then installed web2ldap-0.9.5 to do some tests.
> For what I need it, it works fine. But there still may be problems in=20=

> other
> areas.
>
> I think it's OK to commit the patches to the current branch of CVS. =
Your
> suggestions?
>
> And, yes, as there are no ldap_ufn_* functions in OpenLDAP-2.x, they=20=

> are made
> conditional (#if LDAP_API_VERSION < 2000) in the patches.
> The other known issue is the ldap_rebind_proc callback function, which
> incompatible in OpenLDAP-1.x and 2.x (both arguments, result and=20
> behaviour).
> This requires more study.
>
> Regards,
>     Konstantin.
>
> Christian Wiese wrote:
>
>> Michael,
>>
>> where can I get the OpenLDAP 2.0.16engineering version ?
>> I can test it on my machine because I don't run openldap 1.x
>>
>> Christian
>>
>> Am Tuesday 02 October 2001 19:57 schrieb Michael Str=F6der:
>>> Joe Little wrote:
>>>> what is the openldap 2.x module name from cvs.. I just pulled
>>>> "python-ldap" using the anonymous instructions, and it pulled a =
copy
>>>> with all UFN/etc support still there. like Christian said, he built
>>>> against the current CVS tree. Is this tree "the openldap 2.x" tree=20=

>>>> like
>>>> I think it is. If so, it is littered with ufn/url support :)
>>>
>>> OpenLDAP 2 support not yet there in CVS.
>>>
>>> The most recent and complete OpenLDAP 2 patch I have is the one by
>>> Steffen Ries <ste...@sy...> who tried to come up with
>>> something against CVS containing all the memory leak fixes applied,
>>> Konstantin's patches, Stig's suggestions and his own STARTTLS
>>> support. Not sure about the ufn* stuff though. I've built it against
>>> OpenLDAP 2.0.16engineering from CVS. It works but still seg faults a
>>> lot. Could be an issue with my local installation with OpenLDAP
>>> 1.2.13 hanging around in /usr/lib although
>>> /usr/local/openldap2/lib/libldap.so.2 is used.
>>>
>>> This patched module is used for running web2ldap's online-demo at
>>> http://sites.inka.de:8002/web2ldap with Python 2.
>>>
>>> Ciao, Michael.
>>>
>>> _______________________________________________
>>> Python-LDAP-dev mailing list
>>> Pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>>
>> _______________________________________________
>> Python-LDAP-dev mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
> --
>          * *       Konstantin Chuguev           Francis House
>       *      *     Application Engineer         112 Hills Road
>     *              Tel: +44 1223 302992         Cambridge CB2 1PQ
> D  A  N  T  E      WWW: http://www.dante.net    United Kingdom
>
>
>
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: _ldap problem and current resolution. -- found api change

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

Hi All,

A small update on what I'm doing:
I have merged Steffen Ries's and my patches and built python-ldap with
OpenLDAP-2.0.15. I then installed web2ldap-0.9.5 to do some tests.
For what I need it, it works fine. But there still may be problems in other
areas.

I think it's OK to commit the patches to the current branch of CVS. Your
suggestions?

And, yes, as there are no ldap_ufn_* functions in OpenLDAP-2.x, they are made
conditional (#if LDAP_API_VERSION < 2000) in the patches.
The other known issue is the ldap_rebind_proc callback function, which
incompatible in OpenLDAP-1.x and 2.x (both arguments, result and behaviour).
This requires more study.

Regards,
    Konstantin.

Christian Wiese wrote:

> Michael,
>
> where can I get the OpenLDAP 2.0.16engineering version ?
> I can test it on my machine because I don't run openldap 1.x
>
> Christian
>
> Am Tuesday 02 October 2001 19:57 schrieb Michael Ströder:
> > Joe Little wrote:
> > > what is the openldap 2.x module name from cvs.. I just pulled
> > > "python-ldap" using the anonymous instructions, and it pulled a copy
> > > with all UFN/etc support still there. like Christian said, he built
> > > against the current CVS tree. Is this tree "the openldap 2.x" tree like
> > > I think it is. If so, it is littered with ufn/url support :)
> >
> > OpenLDAP 2 support not yet there in CVS.
> >
> > The most recent and complete OpenLDAP 2 patch I have is the one by
> > Steffen Ries <ste...@sy...> who tried to come up with
> > something against CVS containing all the memory leak fixes applied,
> > Konstantin's patches, Stig's suggestions and his own STARTTLS
> > support. Not sure about the ufn* stuff though. I've built it against
> > OpenLDAP 2.0.16engineering from CVS. It works but still seg faults a
> > lot. Could be an issue with my local installation with OpenLDAP
> > 1.2.13 hanging around in /usr/lib although
> > /usr/local/openldap2/lib/libldap.so.2 is used.
> >
> > This patched module is used for running web2ldap's online-demo at
> > http://sites.inka.de:8002/web2ldap with Python 2.
> >
> > Ciao, Michael.
> >
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

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

working against CVS

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

So, I've applied the latest diff collection which includes StartTLS and 
the mem leak fix.

I'm running into compilation troubles. Configure correctly finds the 2 
arg modrdn2, but it still attempts to use the 3 arg version when it 
compiles. We now have setup.py. Is the use of setup.py now necessary?

Re: new RPMs/diff

[Christian W. <cw...@4i...>]

Hi Joe,

thank you very much for the new rpm.
I've successfully compiled the new package, and it seems to work.
I will try to test it as much as I can, and keep you informed.

Many thanks again,

greetings

Christian

Am Tuesday 02 October 2001 20:03 schrieb Joe Little:
> I've placed on open-it.org the latest release of my python-ldap package in
> the redhat7.1 directory. Release 5 removes the UFN and URL support that
> has caused a problem for post openldap 2.0.11 systems. The "final" patch
> for this release simply removes the code. This may not be ideal. I hope to
> incorporate the latest mem-leak patches against the cvs tree and release
> yet another edition within a week if possible.
>
> Here for posterity is the patch
>
> --- python-ldap-1.10alpha3/Modules/LDAPObject.c.orig	Tue Oct  2 09:47:47
> 2001 +++ python-ldap-1.10alpha3/Modules/LDAPObject.c	Tue Oct  2 10:14:42
> 2001 @@ -1421,149 +1421,6 @@
>
>  /* ldap_search_s == ldap_search_st */
>
> -/* ldap_ufn_search_c */
> -
> -/* ldap_ufn_search_ct */
> -
> -/* ldap_ufn_search_s */
> -
> -static PyObject*
> -l_ldap_ufn_search_s( LDAPObject* self, PyObject* args )
> -{
> -    char *ufn;
> -    PyObject *attrlist;
> -    char **attrs;
> -    int attrsonly = 0;
> -    LDAPMessage *resmsg = NULL;
> -    int result;
> -
> -    if (!PyArg_ParseTuple( args, "sO|i",
> -    	&ufn, &attrlist, &attrsonly)) return NULL;
> -    if (not_valid(self)) return NULL;
> -
> -    if (!attrs_from_List( attrlist, &attrs ))
> -   	 return NULL;
> -
> -    LDAP_BEGIN_ALLOW_THREADS( self );
> -    result = ldap_ufn_search_s( self->ldap, ufn,
> -                             attrs, attrsonly, &resmsg );
> -    LDAP_END_ALLOW_THREADS( self );
> -
> -    free_attrs( &attrs );
> -
> -    if (result != LDAP_SUCCESS)
> -    	return LDAPerror( self->ldap, "ldap_ufn_search_s" );
> -
> -    if (resmsg == NULL) {
> -    	Py_INCREF( Py_None );
> -	return Py_None;
> -    } else {
> -    	return LDAPmessage_to_python( self->ldap, resmsg );
> -    }
> -}
> -
> -
> -/* ldap_ufn_setfilter */
> -
> -static PyObject*
> -l_ldap_ufn_setfilter( LDAPObject* self, PyObject* args )
> -{
> -    char* filter;
> -    LDAPFiltDesc* res;
> -
> -    if (!PyArg_ParseTuple( args, "s", &filter)) return NULL;
> -    if (not_valid(self)) return NULL;
> -    res = ldap_ufn_setfilter( self->ldap, filter );
> -
> -    if (res == NULL)
> -	return LDAPerror(NULL, "ldap_ufn_setfilter");
> -
> -    Py_INCREF( Py_None );
> -    return Py_None;
> -}
> -
> -/* ldap_ufn_setprefix */
> -
> -static PyObject*
> -l_ldap_ufn_setprefix( LDAPObject* self, PyObject* args )
> -{
> -    char* prefix;
> -
> -    if (!PyArg_ParseTuple( args, "s", &prefix)) return NULL;
> -    if (not_valid(self)) return NULL;
> -    ldap_ufn_setprefix( self->ldap, prefix );
> -    Py_INCREF( Py_None );
> -    return Py_None;
> -}
> -
> -static char doc_ufn[] =
> -"ufn_setfilter(filtername) -> None\n"
> -"ufn_setprefix(prefix) -> None\n"
> -"ufn_search_s(url [,attrsonly=0])\n"
> -"ufn_search_st(url [,attrsonly=0 [,timeout=-1]])\n\n"
> -"\tSee the LDAP library manual pages for more information on these\n"
> -"\t`user-friendly name' functions.";
> -
> -/* ldap_sort_entries */
> -
> -/* ldap_url_search */
> -
> -/* ldap_url_search_s */
> -
> -/* ldap_url_search_st */
> -
> -static PyObject*
> -l_ldap_url_search_st( LDAPObject* self, PyObject* args )
> -{
> -    char *url;
> -    int attrsonly = 0;
> -    LDAPMessage *resmsg;
> -    int result;
> -    double timeout = -1.0;
> -    struct timeval tv, *tvp;
> -
> -    if (!PyArg_ParseTuple( args, "s|id", &url, &attrsonly, &timeout ))
> -    	return NULL;
> -    if (not_valid(self)) return NULL;
> -
> -    if (timeout>=0) {
> -        tvp = &tv;
> -	set_timeval_from_double( tvp, timeout );
> -    } else {
> -    	tvp = NULL;
> -    }
> -
> -    LDAP_BEGIN_ALLOW_THREADS( self );
> -    result = ldap_url_search_st( self->ldap, url, attrsonly, tvp, &resmsg
> ); -    LDAP_END_ALLOW_THREADS( self );
> -
> -    if (result != LDAP_SUCCESS)
> -    	return LDAPerror( self->ldap, "ldap_ufn_search_st" );
> -
> -    if (resmsg == NULL) {
> -    	Py_INCREF( Py_None );
> -	return Py_None;
> -    } else {
> -    	return LDAPmessage_to_python( self->ldap, resmsg );
> -    }
> -}
> -
> -static char doc_url_search[] =
> -"url_search_s(url [,attrsonly=0])\n"
> -"url_search_s(url [,attrsonly=0 [,timeout=-1]])\n\n"
> -"\tThese routine works much like search_s*, except that many\n"
> -"\tsearch parameters are pulled out of the URL url.\n"
> -"\n"
> -"\tLDAP URLs look like this:\n"
> -"\t    ldap://host[:port]/dn[?attributes[?scope[?filter]]]\n"
> -"\n"
> -"\twhere scope is one of 'base' (default), 'one' or 'sub',\n"
> -"\tand attributes is a comma-separated list of attributes to\n"
> -"\tbe retrieved.\n"
> -"\n"
> -"\tURLs wrapped in angle-brackets and/or preceded by 'URL:'\n"
> -"\tare tolerated.";
> -
>  /* methods */
>
>  static PyMethodDef methods[] = {
> @@ -1631,11 +1488,6 @@
>      {"search",		(PyCFunction)l_ldap_search,		METH_VARARGS,	doc_search},
>     
> {"search_s",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},
> {"search_st",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search}, - 
>  
> {"ufn_search_s",	(PyCFunction)l_ldap_ufn_search_s,	METH_VARARGS,	doc_ufn},
> -   
> {"ufn_setfilter",	(PyCFunction)l_ldap_ufn_setfilter,	METH_VARARGS,	doc_ufn}
>, -   
> {"ufn_setprefix",	(PyCFunction)l_ldap_ufn_setprefix,	METH_VARARGS,	doc_ufn}
>, -   
> {"url_search_s",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_s
>earch}, -   
> {"url_search_st",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_
>search}, { NULL, NULL }
>  };
>
>
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

new RPMs/diff

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

I've placed on open-it.org the latest release of my python-ldap package in
the redhat7.1 directory. Release 5 removes the UFN and URL support that
has caused a problem for post openldap 2.0.11 systems. The "final" patch
for this release simply removes the code. This may not be ideal. I hope to
incorporate the latest mem-leak patches against the cvs tree and release
yet another edition within a week if possible.

Here for posterity is the patch

--- python-ldap-1.10alpha3/Modules/LDAPObject.c.orig	Tue Oct  2 09:47:47 2001
+++ python-ldap-1.10alpha3/Modules/LDAPObject.c	Tue Oct  2 10:14:42 2001
@@ -1421,149 +1421,6 @@

 /* ldap_search_s == ldap_search_st */

-/* ldap_ufn_search_c */
-
-/* ldap_ufn_search_ct */
-
-/* ldap_ufn_search_s */
-
-static PyObject*
-l_ldap_ufn_search_s( LDAPObject* self, PyObject* args )
-{
-    char *ufn;
-    PyObject *attrlist;
-    char **attrs;
-    int attrsonly = 0;
-    LDAPMessage *resmsg = NULL;
-    int result;
-
-    if (!PyArg_ParseTuple( args, "sO|i",
-    	&ufn, &attrlist, &attrsonly)) return NULL;
-    if (not_valid(self)) return NULL;
-
-    if (!attrs_from_List( attrlist, &attrs ))
-   	 return NULL;
-
-    LDAP_BEGIN_ALLOW_THREADS( self );
-    result = ldap_ufn_search_s( self->ldap, ufn,
-                             attrs, attrsonly, &resmsg );
-    LDAP_END_ALLOW_THREADS( self );
-
-    free_attrs( &attrs );
-
-    if (result != LDAP_SUCCESS)
-    	return LDAPerror( self->ldap, "ldap_ufn_search_s" );
-
-    if (resmsg == NULL) {
-    	Py_INCREF( Py_None );
-	return Py_None;
-    } else {
-    	return LDAPmessage_to_python( self->ldap, resmsg );
-    }
-}
-
-
-/* ldap_ufn_setfilter */
-
-static PyObject*
-l_ldap_ufn_setfilter( LDAPObject* self, PyObject* args )
-{
-    char* filter;
-    LDAPFiltDesc* res;
-
-    if (!PyArg_ParseTuple( args, "s", &filter)) return NULL;
-    if (not_valid(self)) return NULL;
-    res = ldap_ufn_setfilter( self->ldap, filter );
-
-    if (res == NULL)
-	return LDAPerror(NULL, "ldap_ufn_setfilter");
-
-    Py_INCREF( Py_None );
-    return Py_None;
-}
-
-/* ldap_ufn_setprefix */
-
-static PyObject*
-l_ldap_ufn_setprefix( LDAPObject* self, PyObject* args )
-{
-    char* prefix;
-
-    if (!PyArg_ParseTuple( args, "s", &prefix)) return NULL;
-    if (not_valid(self)) return NULL;
-    ldap_ufn_setprefix( self->ldap, prefix );
-    Py_INCREF( Py_None );
-    return Py_None;
-}
-
-static char doc_ufn[] =
-"ufn_setfilter(filtername) -> None\n"
-"ufn_setprefix(prefix) -> None\n"
-"ufn_search_s(url [,attrsonly=0])\n"
-"ufn_search_st(url [,attrsonly=0 [,timeout=-1]])\n\n"
-"\tSee the LDAP library manual pages for more information on these\n"
-"\t`user-friendly name' functions.";
-
-/* ldap_sort_entries */
-
-/* ldap_url_search */
-
-/* ldap_url_search_s */
-
-/* ldap_url_search_st */
-
-static PyObject*
-l_ldap_url_search_st( LDAPObject* self, PyObject* args )
-{
-    char *url;
-    int attrsonly = 0;
-    LDAPMessage *resmsg;
-    int result;
-    double timeout = -1.0;
-    struct timeval tv, *tvp;
-
-    if (!PyArg_ParseTuple( args, "s|id", &url, &attrsonly, &timeout ))
-    	return NULL;
-    if (not_valid(self)) return NULL;
-
-    if (timeout>=0) {
-        tvp = &tv;
-	set_timeval_from_double( tvp, timeout );
-    } else {
-    	tvp = NULL;
-    }
-
-    LDAP_BEGIN_ALLOW_THREADS( self );
-    result = ldap_url_search_st( self->ldap, url, attrsonly, tvp, &resmsg );
-    LDAP_END_ALLOW_THREADS( self );
-
-    if (result != LDAP_SUCCESS)
-    	return LDAPerror( self->ldap, "ldap_ufn_search_st" );
-
-    if (resmsg == NULL) {
-    	Py_INCREF( Py_None );
-	return Py_None;
-    } else {
-    	return LDAPmessage_to_python( self->ldap, resmsg );
-    }
-}
-
-static char doc_url_search[] =
-"url_search_s(url [,attrsonly=0])\n"
-"url_search_s(url [,attrsonly=0 [,timeout=-1]])\n\n"
-"\tThese routine works much like search_s*, except that many\n"
-"\tsearch parameters are pulled out of the URL url.\n"
-"\n"
-"\tLDAP URLs look like this:\n"
-"\t    ldap://host[:port]/dn[?attributes[?scope[?filter]]]\n"
-"\n"
-"\twhere scope is one of 'base' (default), 'one' or 'sub',\n"
-"\tand attributes is a comma-separated list of attributes to\n"
-"\tbe retrieved.\n"
-"\n"
-"\tURLs wrapped in angle-brackets and/or preceded by 'URL:'\n"
-"\tare tolerated.";
-
 /* methods */

 static PyMethodDef methods[] = {
@@ -1631,11 +1488,6 @@
     {"search",		(PyCFunction)l_ldap_search,		METH_VARARGS,	doc_search},
     {"search_s",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},
     {"search_st",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},
-    {"ufn_search_s",	(PyCFunction)l_ldap_ufn_search_s,	METH_VARARGS,	doc_ufn},
-    {"ufn_setfilter",	(PyCFunction)l_ldap_ufn_setfilter,	METH_VARARGS,	doc_ufn},
-    {"ufn_setprefix",	(PyCFunction)l_ldap_ufn_setprefix,	METH_VARARGS,	doc_ufn},
-    {"url_search_s",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},
-    {"url_search_st",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},
     { NULL, NULL }
 };

Re: _ldap problem and current resolution. -- found api change

[Christian W. <cw...@4i...>]

Michael,

where can I get the OpenLDAP 2.0.16engineering version ?
I can test it on my machine because I don't run openldap 1.x

Christian

Am Tuesday 02 October 2001 19:57 schrieb Michael Ströder:
> Joe Little wrote:
> > what is the openldap 2.x module name from cvs.. I just pulled
> > "python-ldap" using the anonymous instructions, and it pulled a copy
> > with all UFN/etc support still there. like Christian said, he built
> > against the current CVS tree. Is this tree "the openldap 2.x" tree like
> > I think it is. If so, it is littered with ufn/url support :)
>
> OpenLDAP 2 support not yet there in CVS.
>
> The most recent and complete OpenLDAP 2 patch I have is the one by
> Steffen Ries <ste...@sy...> who tried to come up with
> something against CVS containing all the memory leak fixes applied,
> Konstantin's patches, Stig's suggestions and his own STARTTLS
> support. Not sure about the ufn* stuff though. I've built it against
> OpenLDAP 2.0.16engineering from CVS. It works but still seg faults a
> lot. Could be an issue with my local installation with OpenLDAP
> 1.2.13 hanging around in /usr/lib although
> /usr/local/openldap2/lib/libldap.so.2 is used.
>
> This patched module is used for running web2ldap's online-demo at
> http://sites.inka.de:8002/web2ldap with Python 2.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: _ldap problem and current resolution. -- found api change

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

Joe Little wrote:
> 
> what is the openldap 2.x module name from cvs.. I just pulled
> "python-ldap" using the anonymous instructions, and it pulled a copy
> with all UFN/etc support still there. like Christian said, he built
> against the current CVS tree. Is this tree "the openldap 2.x" tree like
> I think it is. If so, it is littered with ufn/url support :)

OpenLDAP 2 support not yet there in CVS.

The most recent and complete OpenLDAP 2 patch I have is the one by
Steffen Ries <ste...@sy...> who tried to come up with
something against CVS containing all the memory leak fixes applied,
Konstantin's patches, Stig's suggestions and his own STARTTLS
support. Not sure about the ufn* stuff though. I've built it against
OpenLDAP 2.0.16engineering from CVS. It works but still seg faults a
lot. Could be an issue with my local installation with OpenLDAP
1.2.13 hanging around in /usr/lib although
/usr/local/openldap2/lib/libldap.so.2 is used.

This patched module is used for running web2ldap's online-demo at
http://sites.inka.de:8002/web2ldap with Python 2.

Ciao, Michael.

Re: Problems importing _ldap module

[Christian W. <cw...@4i...>]

with my little experience in C, I removed the ufn functions in LDAPObject.c 
from the CVS source and now can import the ldap module and it seems to 
function.

greetings

Christian

Am Tuesday 02 October 2001 19:17 schrieb Joe Little:
> This is getting interesting
>
> Looks like LDAPObject.c in the Modules directory explicitly call ufn_*
> and these are in turn relied upon by the URL functions. I'm currently
> undergoing surgery on the code, removing the ugly bits AND hoping that
> it will still be functional.
>
> This is not CVS.. just my latest edition.
>
> On Tuesday, October 2, 2001, at 09:36 AM, Christian Wiese wrote:
> > Ok, I understand, but I've never installed OpenLDAP 1.x on this system.
> >
> > Then we should check "LDAPObject.c", regarding this functions.
> >
> > Here are some greps, concerning my configuration:
> >
> > ---------------------------------------------------
> >
> > # rpm -qa | grep openldap
> > openldap-devel-2.0.15-1
> > openldap-clients-2.0.15-1
> > openldap-servers-2.0.15-1
> > openldap-2.0.15-1
> >
> > # rpm -qa | grep python
> > python-xmlrpc-1.4-1
> > python-docs-1.5.2-35
> > pythonlib-1.28-1
> > rpm-python-4.0.3-0.96
> > python-devel-1.5.2-35
> > python-tools-1.5.2-35
> > openssl-python-0.9.6-3
> > mod_python-2.7.3-1
> > python-1.5.2-35
> > python-ldap-python1.5-1.10alpha3-4
> >
> > ---------------------------------------------------
> >
> > Am Tuesday 02 October 2001 18:24 schrieb Michael Ströder:
> >> Christian Wiese wrote:
> >>> but if I try
> >>>
> >>>>>> import ldap
> >>>
> >>> I get the a similar error message.
> >>> [..]
> >>>     from _ldap import __version__
> >>> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so:
> >>> undefined
> >>> symbol: ldap_ufn_setfilter
> >>
> >> Yes, there is a import _ldap in ldap.py anyway. It's just a matter
> >> of module packaging.
> >>
> >> The problem is that in the OpenLDAP 2 libs the support for the
> >> mainly unused functions *ufn* was dropped. Your build of python-ldap
> >> trys to import those old functions which makes me believe that your
> >> _ldapmodule.so was built against OpenLDAP 1 libs.
> >>
> >> Ciao, Michael.
> >
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: Problems importing _ldap module

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

This is getting interesting

Looks like LDAPObject.c in the Modules directory explicitly call ufn_*=20=

and these are in turn relied upon by the URL functions. I'm currently=20
undergoing surgery on the code, removing the ugly bits AND hoping that=20=

it will still be functional.

This is not CVS.. just my latest edition.


On Tuesday, October 2, 2001, at 09:36 AM, Christian Wiese wrote:

> Ok, I understand, but I've never installed OpenLDAP 1.x on this =
system.
>
> Then we should check "LDAPObject.c", regarding this functions.
>
> Here are some greps, concerning my configuration:
>
> ---------------------------------------------------
>
> # rpm -qa | grep openldap
> openldap-devel-2.0.15-1
> openldap-clients-2.0.15-1
> openldap-servers-2.0.15-1
> openldap-2.0.15-1
>
> # rpm -qa | grep python
> python-xmlrpc-1.4-1
> python-docs-1.5.2-35
> pythonlib-1.28-1
> rpm-python-4.0.3-0.96
> python-devel-1.5.2-35
> python-tools-1.5.2-35
> openssl-python-0.9.6-3
> mod_python-2.7.3-1
> python-1.5.2-35
> python-ldap-python1.5-1.10alpha3-4
>
> ---------------------------------------------------
>
> Am Tuesday 02 October 2001 18:24 schrieb Michael Str=F6der:
>> Christian Wiese wrote:
>>> but if I try
>>>
>>>>>> import ldap
>>>
>>> I get the a similar error message.
>>> [..]
>>>     from _ldap import __version__
>>> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so:=20
>>> undefined
>>> symbol: ldap_ufn_setfilter
>>
>> Yes, there is a import _ldap in ldap.py anyway. It's just a matter
>> of module packaging.
>>
>> The problem is that in the OpenLDAP 2 libs the support for the
>> mainly unused functions *ufn* was dropped. Your build of python-ldap
>> trys to import those old functions which makes me believe that your
>> _ldapmodule.so was built against OpenLDAP 1 libs.
>>
>> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: _ldap problem and current resolution. -- found api change

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

Joe Little wrote:
> 
> "Removed -lldap UFN search support".
> 
> Michael, does Python-LDAP expect this to be there?

The ufn* methods are mentioned in
http://python-ldap.sourceforge.net/doc/lib/node9.html. But I suspect
that no serious LDAP application ever made use of this.

> It might be in the
> headers still and so is included (since python-ldap is mostly an
> openldap 1.x beast).

IMHO the *ufn* functions were already dropped in other OpenLDAP 2
patches for python-ldap.

Ciao, Michael.

Re: _ldap problem and current resolution.

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

Joe Little wrote:
> 
> Early analysis of the problem:
> 
> OpenLDAP 2.0.11 does not exhibit this problem. The only other newer
> versions of OpenLDAP that have been packaged by Open-IT are 2.0.14 and
> 2.0.15.

See OpenLDAP 2's CHANGES:

------------------------- snip ---------------------------
OpenLDAP 2.0.12 Release
[..]
        Removed -lldap UFN search support
[..]
------------------------- snip ---------------------------

Ciao, Michael.

Re: Problems importing _ldap module

[Christian W. <cw...@4i...>]

Ok, I understand, but I've never installed OpenLDAP 1.x on this system.

Then we should check "LDAPObject.c", regarding this functions.

Here are some greps, concerning my configuration:

---------------------------------------------------

# rpm -qa | grep openldap
openldap-devel-2.0.15-1
openldap-clients-2.0.15-1
openldap-servers-2.0.15-1
openldap-2.0.15-1

# rpm -qa | grep python
python-xmlrpc-1.4-1
python-docs-1.5.2-35
pythonlib-1.28-1
rpm-python-4.0.3-0.96
python-devel-1.5.2-35
python-tools-1.5.2-35
openssl-python-0.9.6-3
mod_python-2.7.3-1
python-1.5.2-35
python-ldap-python1.5-1.10alpha3-4

---------------------------------------------------

Am Tuesday 02 October 2001 18:24 schrieb Michael Ströder:
> Christian Wiese wrote:
> > but if I try
> >
> > >>>import ldap
> >
> > I get the a similar error message.
> > [..]
> >     from _ldap import __version__
> > ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined
> > symbol: ldap_ufn_setfilter
>
> Yes, there is a import _ldap in ldap.py anyway. It's just a matter
> of module packaging.
>
> The problem is that in the OpenLDAP 2 libs the support for the
> mainly unused functions *ufn* was dropped. Your build of python-ldap
> trys to import those old functions which makes me believe that your
> _ldapmodule.so was built against OpenLDAP 1 libs.
>
> Ciao, Michael.

Re: _ldap problem and current resolution. -- found api change

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

Sorry. I _will try_ to ascertain when this broke. I didn't mean to add 
the "not". Looking at the change log, it would appear that 2.0.12 is the 
likely culprit, as very extraneous files were removed. More 
specifically, one of the last lines is "Removed -lldap UFN search 
support".

Michael, does Python-LDAP expect this to be there? It might be in the 
headers still and so is included (since python-ldap is mostly an 
openldap 1.x beast).

Also, this could very well be my fault since I am not CVS-current. 
However, Christian has already attempted to build against such. Again, I 
suspect some lingering requirement/inclusion in the python-ldap code. 
Still searching..


On Tuesday, October 2, 2001, at 09:32 AM, Joe Little wrote:

> Early analysis of the problem:
>
> OpenLDAP 2.0.11 does not exhibit this problem. The only other newer 
> versions of OpenLDAP that have been packaged by Open-IT are 2.0.14 and 
> 2.0.15.
>
> This likely means an API change in OpenLDAP that is subtle. I rebuilt 
> my RPMs against 2.0.15 and I still see the problem Christian Wiese 
> noted. However, regardless of OpenLDAP built against, the python-ldap 
> module works as long as the openldap 2.0.11 libraries are present. I 
> will not ascertain when this broke post 2.0.11. Likely it means that 
> python-ldap itself needs to address this condition, as it _currently_ 
> appears to be unrelated to the packaging. I of course may still be 
> wrong on that note.
>
>
> On Tuesday, October 2, 2001, at 09:12 AM, Christian Wiese wrote:
>
>> Hi,
>>
>> thank you for your reply and support.
>> In the readme file the module is imported with
>>
>>>>> import _ldap
>>
>> but if I try
>>
>>>>> import ldap
>>
>> I get the a similar error message.
>>
>> -----------------------------------------------
>>
>>>>> import ldap
>> Traceback (innermost last):
>>   File "<stdin>", line 1, in ?
>>   File "/usr/lib/python1.5/site-packages/python-ldap/ldap.py", line 2, 
>> in ?
>>     from _ldap import __version__
>> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: 
>> undefined symbol: ldap_ufn_setfilter
>>>>>
>>
>> ------------------------------------------------
>>
>> Greetings,
>>
>> Christian
>>
>> Am Tuesday 02 October 2001 17:57 schrieb jml...@ma...:
>>> I'll look into this immediately. I also hate to bring up a dead horse,
>>> but are we supposed to import ldap or _ldap?
>>>
>>> On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:
>>>> Hi,
>>>>
>>>> I want to write some python apps for accessing our LDAP server 
>>>> (OpenLDAP
>>>> 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
>>>> I'm using the latest module from Joe Little, which compiles well with
>>>> OpenLDAP 2.0.15
>>>>
>>>> This is the error message I get from python:
>>>>
>>>> -------------------------------------------------------
>>>>
>>>> Python 1.5.2 (#1, Sep 22 2001, 18:07:47)  [GCC 2.96 20000731 (Red Hat
>>>> Linux
>>>> 7.1 2 on linux-i386
>>>> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>>
>>>>>>> import _ldap
>>>>
>>>> Traceback (innermost last):
>>>>   File "<stdin>", line 1, in ?
>>>> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: 
>>>> undefined
>>>> symbol: ldap_ufn_setfilter
>>>>
>>>>
>>>> -------------------------------------------------------
>>>>
>>>> Does anybody have an idea, for solving this problem ?
>>>>
>>>> Thank you in advance for any help or suggestions,
>>>>
>>>> Best regards,
>>>>
>>>> Christian
>>>>
>>>> _______________________________________________
>>>> Python-LDAP-dev mailing list
>>>> Pyt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>>
>
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

_ldap problem and current resolution.

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

Early analysis of the problem:

OpenLDAP 2.0.11 does not exhibit this problem. The only other newer 
versions of OpenLDAP that have been packaged by Open-IT are 2.0.14 and 
2.0.15.

This likely means an API change in OpenLDAP that is subtle. I rebuilt my 
RPMs against 2.0.15 and I still see the problem Christian Wiese noted. 
However, regardless of OpenLDAP built against, the python-ldap module 
works as long as the openldap 2.0.11 libraries are present. I will not 
ascertain when this broke post 2.0.11. Likely it means that python-ldap 
itself needs to address this condition, as it _currently_ appears to be 
unrelated to the packaging. I of course may still be wrong on that note.


On Tuesday, October 2, 2001, at 09:12 AM, Christian Wiese wrote:

> Hi,
>
> thank you for your reply and support.
> In the readme file the module is imported with
>
>>>> import _ldap
>
> but if I try
>
>>>> import ldap
>
> I get the a similar error message.
>
> -----------------------------------------------
>
>>>> import ldap
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python1.5/site-packages/python-ldap/ldap.py", line 2, 
> in ?
>     from _ldap import __version__
> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined 
> symbol: ldap_ufn_setfilter
>>>>
>
> ------------------------------------------------
>
> Greetings,
>
> Christian
>
> Am Tuesday 02 October 2001 17:57 schrieb jml...@ma...:
>> I'll look into this immediately. I also hate to bring up a dead horse,
>> but are we supposed to import ldap or _ldap?
>>
>> On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:
>>> Hi,
>>>
>>> I want to write some python apps for accessing our LDAP server 
>>> (OpenLDAP
>>> 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
>>> I'm using the latest module from Joe Little, which compiles well with
>>> OpenLDAP 2.0.15
>>>
>>> This is the error message I get from python:
>>>
>>> -------------------------------------------------------
>>>
>>> Python 1.5.2 (#1, Sep 22 2001, 18:07:47)  [GCC 2.96 20000731 (Red Hat
>>> Linux
>>> 7.1 2 on linux-i386
>>> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>
>>>>>> import _ldap
>>>
>>> Traceback (innermost last):
>>>   File "<stdin>", line 1, in ?
>>> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: 
>>> undefined
>>> symbol: ldap_ufn_setfilter
>>>
>>>
>>> -------------------------------------------------------
>>>
>>> Does anybody have an idea, for solving this problem ?
>>>
>>> Thank you in advance for any help or suggestions,
>>>
>>> Best regards,
>>>
>>> Christian
>>>
>>> _______________________________________________
>>> Python-LDAP-dev mailing list
>>> Pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: Problems importing _ldap module

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

this is a new patching scheme provided to me. It allows for builds=20
against python1.5, 2.0, and 2.1. As for the patches, have only taken the=20=

posted patches to date and have not yet used CVS since it was in flux.=20=

What would be the current ideal flags to CVS to pull out an OpenLDAP 2.0=20=

version. Is it HEAD?

On Tuesday, October 2, 2001, at 09:26 AM, Michael Str=F6der wrote:

> Joe Little wrote:
>>
>> python-ldap-python1.5-1.10alpha3-4.i386.rpm, correct?
>                         ^^^^^^^^^^
>
> This version number is misleading since you patched python-ldap. And
> any reasons why you're not using recent CVS tree for applying the
> patches? There were important memory leak fixes since 1.10alpha3.
>
> Ciao, Michael.
>

Re: Problems importing _ldap module

[Christian W. <cw...@4i...>]

Yep, that's right ...


Am Tuesday 02 October 2001 18:08 schrieb Joe Little:
> Ok.. to make sure we are all on the the same page. You are using RedHat
> 7.1 with Open-IT's openldap-2.0.15 RPMS, as well as the
> python-ldap-python1.5-1.10alpha3-4.i386.rpm, correct? I want to make
> sure I match your setup exactly.
>
> On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:
> > Hi,
> >
> > I want to write some python apps for accessing our LDAP server (OpenLDAP
> > 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
> > I'm using the latest module from Joe Little, which compiles well with
> > OpenLDAP 2.0.15
> >
> > This is the error message I get from python:
> >
> > -------------------------------------------------------
> >
> > Python 1.5.2 (#1, Sep 22 2001, 18:07:47)  [GCC 2.96 20000731 (Red Hat
> > Linux
> > 7.1 2 on linux-i386
> > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >
> >>>> import _ldap
> >
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined
> > symbol: ldap_ufn_setfilter
> >
> >
> > -------------------------------------------------------
> >
> > Does anybody have an idea, for solving this problem ?
> >
> > Thank you in advance for any help or suggestions,
> >
> > Best regards,
> >
> > Christian
> >
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: Problems importing _ldap module

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

Joe Little wrote:
> 
> python-ldap-python1.5-1.10alpha3-4.i386.rpm, correct?
                        ^^^^^^^^^^

This version number is misleading since you patched python-ldap. And
any reasons why you're not using recent CVS tree for applying the
patches? There were important memory leak fixes since 1.10alpha3.

Ciao, Michael.

Re: Problems importing _ldap module

[Christian W. <cw...@4i...>]

you are right, and I read the faq before, but I found also a special rpm 
package from Joe, which is linked against OpenLDAP 2.x.x libs. There are also 
some patches in it.

see:

http://python-ldap.sourceforge.net/download.shtml

The CVS sources should also work with OpenLDAP 2.x.x libs.


Am Tuesday 02 October 2001 18:11 schrieb Michael Ströder:
> Christian Wiese wrote:
> > Then I compiled the "official" released sources, and I found the same
> > warnings again.
>
> Compiling the "official" released sources and OpenLDAP 2 libs:
> See item 3 on: http://python-ldap.sf.net/faq.shtml
>
> It's still up-to-date.
>
> Ciao, Michael.

Re: Problems importing _ldap module

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

Christian Wiese wrote:
> 
> but if I try
> 
> >>>import ldap
> 
> I get the a similar error message.
> [..]
>     from _ldap import __version__
> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined symbol: ldap_ufn_setfilter
> >>>

Yes, there is a import _ldap in ldap.py anyway. It's just a matter
of module packaging. 

The problem is that in the OpenLDAP 2 libs the support for the
mainly unused functions *ufn* was dropped. Your build of python-ldap
trys to import those old functions which makes me believe that your
_ldapmodule.so was built against OpenLDAP 1 libs.

Ciao, Michael.