python-ldap-dev

compilation error

[Peter P. <pet...@fi...>]

I am trying to install web2ldap software which requires python-ldap version
1.8 or higher. The author of web2ldap provided me with the package
python-ldap-CVS-20010510.tar.gz which I tried to install in my RH 7.1 system
which has the following packages installed:

--snip--
python2-2.1-4 (from python.org)
python2-tkinter-2.1-4
python2-devel-2.1-4
python2-tools-2.1-4

python-2.0-14 (from rpmfind.net, built for ConnectivaLinux)
python-devel-2.0-14

python-xmlrpc-1.4-1 (from RH7.1 CD)
rpm-python-4.0.2-8

openldap-2.0.7-14 (from RH7.1 CD)
openldap-servers-2.0.7-14
openldap-clients-2.0.7-14
openldap-devel-2.0.7-14
openldap12-1.2.11-4

krbafs-1.0.5-1 (from RH7.1 CD)
pam_krb5-1.31-1

krb5-libs-1.2.2-5 (from RH7.1 Updates)
krb5-workstation-1.2.2-5
krb5-devel-1.2.2-5
krb5-server-1.2.2-5
--snip--

I configured python-ldap:

--snip--
[root@jolo python-ldap]# ./configure --with-ldap-lib=/usr/lib
--with-ldap-inc=/usr/include --with-python=/usr/bin/python2.1 --with-kerberos
--with-kerberos-lib=/usr/kerberos/lib
--snip--

And then tried to run make:

--snip--
[root@jolo python-ldap]# make
cd Modules && make srcdir=/usr/src/python-ldap/Modules
VPATH=/usr/src/python-ldap/Modules
make[1]: Entering directory `/usr/src/python-ldap/Modules'
gcc -fPIC -g -O2 -Wall -Wstrict-prototypes -I/usr/include/python2.1
-I/usr/include/python2.1 -DHAVE_CONFIG_H  -I. -DLDAP_REFERRALS -I/usr/include
-c /usr/src/python-ldap/Modules/./constants.c -o ./constants.o
/usr/src/python-ldap/Modules/./constants.c: In function `LDAPinit_constants':
/usr/src/python-ldap/Modules/./constants.c:69: `LDAP_MAX_ATTR_LEN' undeclared
(first use in this function)
/usr/src/python-ldap/Modules/./constants.c:69: (Each undeclared identifier is
reported only once
/usr/src/python-ldap/Modules/./constants.c:69: for each function it appears
in.)
/usr/src/python-ldap/Modules/./constants.c:82: `LDAP_REQ_UNBIND_30' undeclared
(first use in this function)
/usr/src/python-ldap/Modules/./constants.c:83: `LDAP_REQ_DELETE_30' undeclared
(first use in this function)
/usr/src/python-ldap/Modules/./constants.c:84: `LDAP_REQ_ABANDON_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:109: `LDAP_AUTH_SIMPLE_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:110: `LDAP_AUTH_KRBV41_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:111: `LDAP_AUTH_KRBV42_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:121: `LDAP_FILTER_PRESENT_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:125: `LDAP_SUBSTRING_INITIAL_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:126: `LDAP_SUBSTRING_ANY_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:127: `LDAP_SUBSTRING_FINAL_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:138: `LDAP_DEFAULT_REFHOPLIMIT'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:164: `LDAP_URL_ERR_NOTLDAP'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:165: `LDAP_URL_ERR_NODN' undeclared
(first use in this function)
make[1]: *** [constants.o] Error 1
make[1]: Leaving directory `/usr/src/python-ldap/Modules'
make: *** [_ldapmodule-build] Error 2
--snip--

I get the same error if I try to recompile the .src.rpm found at
http://www.webideal.de/ldap/.

Any help appreciated,

Peter

Re: compilation error

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

Peter Peltonen wrote:
> 
> openldap-devel-2.0.7-14
> openldap12-1.2.11-4

I'd suggest that you try to grab OpenLDAP 1.2.12 sources and compile
them yourself in a local directory for making sure that the OpenLDAP
libs are not mixed up:

In directory openldap-1.2.12/ invoke:
./configure
make depend
make

Then go to the python-ldap source directory:

./configure --prefix=/usr --with-python=/usr/bin/python2.1
--with-ldap-lib=/home/michael/src/openldap-1.2.12/libraries
--with-ldap-inc=/home/michael/src/openldap-1.2.12/include
make
make install

> krbafs-1.0.5-1 (from RH7.1 CD)
> pam_krb5-1.31-1
> krb5-libs-1.2.2-5 (from RH7.1 Updates)
> krb5-workstation-1.2.2-5
> krb5-devel-1.2.2-5
> krb5-server-1.2.2-5

Note: web2ldap is not Kerberos-aware yet.

Ciao, Michael.

Re: compilation error

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

you'll notice that 1.2.x will slowly be unsupported/unavailable. If
nothing else, the OpenLDAP 2.x patches should like become proper to the
source tree so that users can use any modern system.

Also, there is a bug in my packages that I just noticed. The makefile for
python-ldap does not explicitly install _ldapmodule.so in the python path=
,
so an RPM actually doesn't see it (alternative build root). I've made a
new RPM but I'm stuck on a lousy windows box for my net connection at the
moment. Happily, I have Zope working with python-ldap as of this morning.

My current solution to the above problem is to install _ldapmodule.so int=
o
/usr/lib/py*/site-packages alogn with ldap.pth. This way, packagers will
get it with "make DESTDIR=3DALTROOT/blah/blah"

		-Joe

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

> Peter Peltonen wrote:
> >
> > openldap-devel-2.0.7-14
> > openldap12-1.2.11-4
>
> I'd suggest that you try to grab OpenLDAP 1.2.12 sources and compile
> them yourself in a local directory for making sure that the OpenLDAP
> libs are not mixed up:
>
> In directory openldap-1.2.12/ invoke:
> ./configure
> make depend
> make
>
> Then go to the python-ldap source directory:
>
> ./configure --prefix=3D/usr --with-python=3D/usr/bin/python2.1
> --with-ldap-lib=3D/home/michael/src/openldap-1.2.12/libraries
> --with-ldap-inc=3D/home/michael/src/openldap-1.2.12/include
> make
> make install
>
> > krbafs-1.0.5-1 (from RH7.1 CD)
> > pam_krb5-1.31-1
> > krb5-libs-1.2.2-5 (from RH7.1 Updates)
> > krb5-workstation-1.2.2-5
> > krb5-devel-1.2.2-5
> > krb5-server-1.2.2-5
>
> Note: web2ldap is not Kerberos-aware yet.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: compilation error

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

Joe Little wrote:
> 
> you'll notice that 1.2.x will slowly be unsupported/unavailable.

OpenLDAP 1.2.x is actively maintained. See the recent 1.2.12 release
a couple of days ago.

> If nothing else, the OpenLDAP 2.x patches should like become
> proper to the source tree so that users can use any modern system.

Unfortunately your patch for linking python-ldap against OpenLDAP
2.0.x breaks some existing python-ldap code (deref, alias options)
without giving extra functionality. Look into Konstantin's patch
which is a little bit more complete regarding LDAP options.

We already had this discussion on-list and off-list several
times. Up to now *nobody* raised his virtual hand saying "I will do
it, maintain it for at least a couple of months and write
documentation". David is not available for working on it at the
moment.

Although I personally don't like a SWIG approach I already made
suggestions how I could contribute to a SWIG-based low-level LDAP
API by writing a nice Python wrapper above it. This means I'm really
willing to put my time into this. I'm still waiting for at least one
serious response from the SWIG crowd saying "Yes, I will do it!". I
had a short look at the swig-ldap code posted by Sascha but could
not compile it on my box.

The argument that OpenLDAP 2.x is more modern does not stand for its
own.
Solaris developers could argue that Solaris already ships with
Netscape/Mozilla SDK which is quite incompatible to the OpenLDAP 2.x
libs - but thread-safe. Which way to go? My question regarding which
SDK to choose was not answered by anybody here yet. It was not even
discussed at all!

Just to show you one example how detailed problems are:
Today I experienced that OpenLDAP 2.0.10 has a slightly different
behaviour regarding referrals with Konstantin's python-ldap patches
than OpenLDAP 2.0.7. If you actually don't have to deal with these
kind of problems it's far less hassle to stick to the OpenLDAP 1.2.x
libs until one of you really bites the bullet and does the heavy
work.

I repeat myself: A couple of patches will not fit the bill because
otherwise people will complain that it's immature and unusable.

Ciao, Michael.

Re: compilation error

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

BTW -- can anyone post to the list the most recent patches (Konstanin's)

I'll grab them soon. I'll be connected to the net every other day for a
bit, and the connection is so slow.. no web surfeing for me.

As to the message, you have valid points. From my standpoint, the problem=
s
require further research, so any reply would be less than adequate at thi=
s
stage..


On Thu, 24 May 2001, Michael Str=F6der wrote:

> Joe Little wrote:
> >
> > you'll notice that 1.2.x will slowly be unsupported/unavailable.
>
> OpenLDAP 1.2.x is actively maintained. See the recent 1.2.12 release
> a couple of days ago.
>
> > If nothing else, the OpenLDAP 2.x patches should like become
> > proper to the source tree so that users can use any modern system.
>
> Unfortunately your patch for linking python-ldap against OpenLDAP
> 2.0.x breaks some existing python-ldap code (deref, alias options)
> without giving extra functionality. Look into Konstantin's patch
> which is a little bit more complete regarding LDAP options.
>
> We already had this discussion on-list and off-list several
> times. Up to now *nobody* raised his virtual hand saying "I will do
> it, maintain it for at least a couple of months and write
> documentation". David is not available for working on it at the
> moment.
>
> Although I personally don't like a SWIG approach I already made
> suggestions how I could contribute to a SWIG-based low-level LDAP
> API by writing a nice Python wrapper above it. This means I'm really
> willing to put my time into this. I'm still waiting for at least one
> serious response from the SWIG crowd saying "Yes, I will do it!". I
> had a short look at the swig-ldap code posted by Sascha but could
> not compile it on my box.
>
> The argument that OpenLDAP 2.x is more modern does not stand for its
> own.
> Solaris developers could argue that Solaris already ships with
> Netscape/Mozilla SDK which is quite incompatible to the OpenLDAP 2.x
> libs - but thread-safe. Which way to go? My question regarding which
> SDK to choose was not answered by anybody here yet. It was not even
> discussed at all!
>
> Just to show you one example how detailed problems are:
> Today I experienced that OpenLDAP 2.0.10 has a slightly different
> behaviour regarding referrals with Konstantin's python-ldap patches
> than OpenLDAP 2.0.7. If you actually don't have to deal with these
> kind of problems it's far less hassle to stick to the OpenLDAP 1.2.x
> libs until one of you really bites the bullet and does the heavy
> work.
>
> I repeat myself: A couple of patches will not fit the bill because
> otherwise people will complain that it's immature and unusable.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: compilation error

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

On Thu, 24 May 2001, Joe Little typed thusly:

> BTW -- can anyone post to the list the most recent patches (Konstanin's)

shame on you! ;) go to the python-ldap web page, click on mailing list archive,
type 'konstantin patch' in the search field... and the first result is:

http://www.geocrawler.com/archives/3/1568/2000/11/0/4676963/

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: compilation error

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

thanks.. not good net acces

On Fri, 25 May 2001, David Leonard wrote:

> On Thu, 24 May 2001, Joe Little typed thusly:
>
> > BTW -- can anyone post to the list the most recent patches (Konstanin's)
>
> shame on you! ;) go to the python-ldap web page, click on mailing list archive,
> type 'konstantin patch' in the search field... and the first result is:
>
> http://www.geocrawler.com/archives/3/1568/2000/11/0/4676963/
>
> d
>

Re: compilation error

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

Does anyone out there have original copies of these? The mailing list
softwre did a good munge job on it.

For instance, in the errors.c patch it has a nonsensical:


     +#if defined(LDAP_API_VERSION)
     +               if (ldap_get_option(l, LDAP_OPT_MATCHED_DN, &matched)
>= 0
     +                       && matched != NULL) {
     +                   if (*matched != `f, name );
     +#endif /* defined(LDAP_API_VERSION) */
      }

      /* set attribute */
     @@ -1798,7 +1865,12 @@
      static int
      setattr( LDAPObject* self, char* name, PyObject* value )
      {
     +#if defined(LDAP_API_VERSION)

First, `f, name doesn't work. Second, I found out that the file being
edited was actually LDAPObject.c and not errors.c at that point. A whole
segment is thus missing and a 4th file should be in the MMIME encode. The
message is offically screwed :)

To quickly answer your last message, the package did not use the setup.py
component. I'm using hte non-CVS version of 1.10a3. Should ther be another
"release" this stage just to seperate things? Maybe a4 or b1?



On Fri, 25 May 2001, David Leonard wrote:

> On Thu, 24 May 2001, Joe Little typed thusly:
>
> > BTW -- can anyone post to the list the most recent patches (Konstanin's)
>
> shame on you! ;) go to the python-ldap web page, click on mailing list archive,
> type 'konstantin patch' in the search field... and the first result is:
>
> http://www.geocrawler.com/archives/3/1568/2000/11/0/4676963/
>
> d
>

Re: compilation error

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

On Thu, 24 May 2001, Joe Little typed thusly:

> Does anyone out there have original copies of these? The mailing list
> softwre did a good munge job on it.

choose the 'Print' option at the top of the web page. you'll get a 'raw'
version of the message which you can save to a file, or pipe straight into
patch if you're keen.

> To quickly answer your last message, the package did not use the setup.py
> component. I'm using hte non-CVS version of 1.10a3. Should ther be another
> "release" this stage just to seperate things? Maybe a4 or b1?

mmmm, release... everyone is eager to do an interim release.
I think 1.10 could be "released" by just renaming 1.10a3 to 1.10 :)

1.11 can also appear soon. it just needs a little more removing of
non-openldapisms testing and then packaging.

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: compilation error

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

David Leonard wrote:
> 
> mmmm, release... everyone is eager to do an interim release.
> I think 1.10 could be "released" by just renaming 1.10a3 to 1.10 :)

No! That's not right. Review the CVS logs!

There were patches after 1.10a3 adressing proper handling of (error)
results of ldap_result (also by Konstantin) which slightly changes
the result returned by LDAPObject.result() method in case of no
result received. (Uuuh, did anybody of you understand this sentence?
;-)

AFAIK also another memory leak was fixed (if you didn't loose the
patch... ;-).

> 1.11 can also appear soon. it just needs a little more removing of
> non-openldapisms testing and then packaging.

No! Just leave it as it is. Please, please...

Call it 1.11 to avoid confusion because *it is* significantly
different from 1.10a3. But it's stable.

Ciao, Michael.

Re: compilation error

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

Joe Little wrote:
> 
> Does anyone out there have original copies of these? The mailing list
> softwre did a good munge job on it.

I've attached a tar.gz containing the diffs.

> To quickly answer your last message, the package did not use the setup.py
> component. I'm using hte non-CVS version of 1.10a3. Should ther be another
> "release" this stage just to seperate things? Maybe a4 or b1?

Yes. I'd also suggest to make a 1.11 release before doing anything
else. The CVS version without any OpenLDAP 2.0.x related stuff works
pretty well.

Ciao, Michael.