python-ldap-dev

Win32 Binaries?

[Jerry L. <te...@ho...>]

Hi All,

Just got this e-mail from Volker Wend who has built Win32 binaries of 
python-ldap here
http://www.zope.org/Members/volkerw/LdapWin32/python-ldap-2.0.0pre11.win32.zip/view
They were built against Python 2.1 and I need something built against 2.2

------------------
I have the Python2.2 Binaries already working. I just forgot to upload those
to zope.org, Since they are now transitioning to a new site. I will wait
untill that is finished...

Regarding building OpenLdap and Python LDAP: I compiled the OpenLdap Library
myself and then python-ldap. Its too long to explain ...
------------------
Thanks Volker!

Jerry.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

Jerry Lee wrote:

> Hi All,
>
> Just got this e-mail from Volker Wend who has built Win32 binaries of 
> python-ldap here
> http://www.zope.org/Members/volkerw/LdapWin32/python-ldap-2.0.0pre11.win32.zip/view 
>
> They were built against Python 2.1 and I need something built against 2.2
>
> ------------------
> I have the Python2.2 Binaries already working. I just forgot to upload 
> those
> to zope.org, Since they are now transitioning to a new site. I will wait
> untill that is finished...
>
> Regarding building OpenLdap and Python LDAP: I compiled the OpenLdap 
> Library
> myself and then python-ldap. Its too long to explain ...
> ------------------
> Thanks Volker!
>
> Jerry.

Hi everybody,
I have finally managed and gathered the time to compile Python LDAP on 
Win32, too.

I pulled the sources from CVS two days ago and compiled against all of 
the new versions of OpenLDAP (2.1.22) and Python (2.3) (and the very 
latest cyrus-sasl, for that matter).
I did not link OpenSSL in since I'm waiting for feedback from the 
OpenLDAP developers: just compiling *that* under Windows is a pain, as 
Volker probably knows... and I'm not sure how to pull the SSL/TLS 
support in properly.

If anyone's interested, I have the binaries available now. I will post 
them on my homepage (http://www.siosistemi.it/~mcicogni/) today or 
tomorrow, although they lack a nice installer.

This is because for some reason the distutils script does not work 
anymore with my old setup.cfg which used to work beautifully with Python 
2.2.
Is there anyone familiar with these topics that can lend me a hand?

Thanks in advance,
Mauro

Re: Win32 Binaries?

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

Mauro Cicognini wrote:
> 
> I have finally managed and gathered the time to compile Python LDAP on 
> Win32, too.
> [..]
> This is because for some reason the distutils script does not work 
> anymore with my old setup.cfg which used to work beautifully with Python 
> 2.2.
> Is there anyone familiar with these topics that can lend me a hand?

I'm not really familiar with compiling under Win32 but I'd be interested in 
finding out the issues with setup.cfg.

Can you please post your old setup.cfg and the one the build went fine with?

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

# Section for compiling the C extension module
# for wrapping OpenLDAP 2 libs

[_ldap]
class = OpenLDAP2
library_dirs = D:/users/mcicogni/sviluppo/openldap/openldap-2.0.23/Release D:/users/mcicogni/sviluppo/openldap/cyrus-sasl-1.5.27/win32/libsasl/Release
include_dirs = D:/users/mcicogni/sviluppo/openldap/openldap-2.0.23/include
libs = olber32 oldap32 ws2_32 libsasl
defines = WIN32

# Installation options

[install]

compile = 1
optimize = 1

Re: Win32 Binaries?

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

Mauro,

thanks for your response. I'm very much interested in getting these issues 
solved.

Mauro Cicognini wrote:
> I attach the old setup.cfg from PythonLDAP 2.0.0pre04 that used to work 
> perfectly. I *had* hacked setup.py a little bit then, to make it simple 
> to define symbols. BTW, the particular symbol I need is just "WIN32".

Can you please post your setup.py hack?

>    1. There's no way (AFAIK) to simply "define" a preprocessor symbol
>       within setup.cfg. The distutils scripts expect to have a list of
>       one- or two-element tuples, but the parser has no way to pull
>       those from the .cfg. Besides, the one-element tuple means to
>       "undefine" the symbol, whereas I'd like to just "define" it
>       without giving it a value, which is unnecessary. I managed to
>       insert it using a crude hack within setup.py (just as I had done
>       with the earlier version), but I do not like this solution.

Wouldn't

extra_compile_args = -DWIN32

help?

I can also modify setup.py to properly build the two-tuple list of defines 
from a line (see attached diff)

defines = WIN32

>    2. The "HAVE_XXX" symbol definition in setup.py is Linux-centric:
>       since the libraries under Windows have slightly different names
>       (for instance, "olber32" instead of just "lber"), those symbols
>       would just not get defined. This however was simple enough to fix.

Mainly the HAVE_LIBLDAP_R is of interest. How's the libldap_r called on 
Windows? Additionally you can try to manually set -DHAVE_LIBLDAP_R etc. in 
setup.cfg.

>    3. It appears that any library path under "library_dirs" for some
>       reason gets copied over to "runtime_library_dirs", which makes no
>       sense to me.

No clue why David did it. I removed it and it stills builds under Linux. I'd 
appreciate if others test it on different platforms.

>    4. The linker get called without the default libraries, and in such a
>       way that a whole lot of symbols are found twice, so it just barfs
>       and never links.

Any clue how to solve that?

> After these unsuccessful attempts, I had modified setup.py (which could 
> be OK)

Please post your modifications to setup.py. Proposals welcome.

> but I had also started changing the default Python library 
> scripts, and I'm not comfortable with this.

This is certainly no option.

> So I pulled up the old MSVC 
> project I used for PythonLDAP 1.x, worked on it for a while and got the 
> library to compile nicely.

My goal is to have a setup.py which is suitable to build python-ldap on any 
platform with a platform-specific setup.cfg. So let's sort out the issues 
together. I don't have a Win32 system to test a build therefore your input 
is highly appreciated.

I've attached a unified diff for setup.py. Please test.

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

Michael Str=F6der wrote:

> Mauro,
>
> thanks for your response. I'm very much interested in getting these=20
> issues solved.
>
> Mauro Cicognini wrote:
>
>> I attach the old setup.cfg from PythonLDAP 2.0.0pre04 that used to=20
>> work perfectly. I *had* hacked setup.py a little bit then, to make it =

>> simple to define symbols. BTW, the particular symbol I need is just=20
>> "WIN32".
>
>
> Can you please post your setup.py hack?

Well, it really is functionally identical to the modifications in your=20
diff that do the same thing :-)

What I added was:

if cfg.has_section('_ldap'):
    if cfg.has_option('_ldap', 'class'):
        LDAP_CLASS =3D eval(cfg.get('_ldap', 'class'))
    else:
        LDAP_CLASS =3D OpenLDAP2
    for name in LDAP_CLASS.__dict__.keys():
        if cfg.has_option('_ldap', name):
            setattr(LDAP_CLASS, name, string.split(cfg.get('_ldap', name)=
))
+   if cfg.has_option('_ldap', 'defines'):
+      for defname in string.split(cfg.get('_ldap', 'defines')):
+          LDAP_CLASS.defines.append((defname, None))

but I like your solution better.

>    1. There's no way (AFAIK) to simply "define" a preprocessor symbol
>
>>       within setup.cfg. The distutils scripts expect to have a list of=

>>       one- or two-element tuples, but the parser has no way to pull
>>       those from the .cfg. Besides, the one-element tuple means to
>>       "undefine" the symbol, whereas I'd like to just "define" it
>>       without giving it a value, which is unnecessary. I managed to
>>       insert it using a crude hack within setup.py (just as I had done=

>>       with the earlier version), but I do not like this solution.
>
>
> Wouldn't
>
> extra_compile_args =3D -DWIN32
>
> help?

As I said, I am not familiar with distutils at all. Yes, it would help,=20
I only wasn't really thinking <:-)

>
> I can also modify setup.py to properly build the two-tuple list of=20
> defines from a line (see attached diff)
>
> defines =3D WIN32

As I said, I would like this. I second your implementation.

>
>>    2. The "HAVE_XXX" symbol definition in setup.py is Linux-centric:
>>       since the libraries under Windows have slightly different names
>>       (for instance, "olber32" instead of just "lber"), those symbols
>>       would just not get defined. This however was simple enough to fi=
x.
>
>
> Mainly the HAVE_LIBLDAP_R is of interest. How's the libldap_r called=20
> on Windows? Additionally you can try to manually set -DHAVE_LIBLDAP_R=20
> etc. in setup.cfg.

The current OpenLDAP version calls it oldap_r.lib.

>
>>    3. It appears that any library path under "library_dirs" for some
>>       reason gets copied over to "runtime_library_dirs", which makes n=
o
>>       sense to me.
>
>
> No clue why David did it. I removed it and it stills builds under=20
> Linux. I'd appreciate if others test it on different platforms.

I removed it too, and didn't hurt. I'm wondering too.

>
>>    4. The linker get called without the default libraries, and in such=
 a
>>       way that a whole lot of symbols are found twice, so it just barf=
s
>>       and never links.
>
>
> Any clue how to solve that?

None whatsoever :-(

I'll work on this more next week, I'll let you know.

>
> My goal is to have a setup.py which is suitable to build python-ldap=20
> on any platform with a platform-specific setup.cfg.

Me too. I loved the friendly binary installer I got with 2.0.0pre04 :-)

> So let's sort out the issues together. I don't have a Win32 system to=20
> test a build therefore your input is highly appreciated. I've attached =

> a unified diff for setup.py. Please test.

I will, more on this next week (tomorrow is a national holiday here ;-).

Thanks a lot and keep up the great work.

BR,
Mauro

Re: Win32 Binaries?

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

Mauro Cicognini wrote:
 >
 >> I can also modify setup.py to properly build the two-tuple list of
 >> defines from a line (see attached diff)
 >>
 >> defines = WIN32
 >
 > As I said, I would like this. I second your implementation.
 > [..]
 >>>    3. It appears that any library path under "library_dirs" for some
 >>>       reason gets copied over to "runtime_library_dirs", which makes no
 >>>       sense to me.
 >>
 >> No clue why David did it. I removed it and it stills builds under
 >> Linux. I'd appreciate if others test it on different platforms.
 >
 > I removed it too, and didn't hurt. I'm wondering too.

Ok, checked in both changes in setup.py.

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

Hi all,
it looks like I do have a setup.cfg that builds correctly under win32. I 
attach it here.
(BTW Michael, how would you let the different setp.cfg versions 
co-exist? Should we put the Win32 one under the Win32 directory? That 
particular directory used to host the old build files that I had cobbled 
together manually to build python-ldap 1.x. In fact I could also provide 
the new versions of those, for those folks who are more comfortable with 
the GUI (which does not build the nice graphical installer, though)).

I did have to extend setup.py a bit; I attach the unified diff here.
In fact, I also think that it's better to put the whole of "ldap" and 
"ldap.schema" as "packages" (in distutils jargon) rather than inserting 
every individual file by hand into setup.py as a "module". So I took the 
liberty of changing that, too, and that is reflected into the diff. Many 
more lines seem to have changed but it's just an artefact of having 
reformatted the whole file to use consistently 4-space tabs everywhere. 
Please forgive me if this conflicts with anyone else's tabbing style.

The only feature missing at this time is SSL support; the OpenLDAP guys 
haven't finished the port for Win32 and there are also "political" 
tangles so it isn't clear what's going to happen. I do hope they will 
get their act together sometime in the near future, since they claim 
that Windows is now one of the "officially supported" platforms. So I 
hope for interesting developments Very Soon Now.

Now, what I have is a nice graphical installer of Python-ldap 2.0.0pre14 
for Python 2.3. All one had to do is download it and double-click it. I 
was amazed at the amount of work the distutils guys have done; it even 
plugs in nicely with the "uninstall" features of Windows. As an added 
convenience, I made it install the SASL DLL. LDAP support is linked in 
statically, which is handier.

I have built python-ldap (and everything else) using the new .NET 
compiler, which is different than the version used to build the Python 
distribution; however, in my tests everything runs smoothly. I'd love to 
have someone else test my work, since I have limited testing possibilities.

So, please anyone interested let me know and I'll mail you the setup 
exe. I'd attach it here but I doubt that it would be very interesting 
for the majority of the readers of this list.

BR,
Mauro

Re: Win32 Binaries?

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

Mauro Cicognini wrote:
> it looks like I do have a setup.cfg that builds correctly under win32.

Thanks for working on it.

> (BTW Michael, how would you let the different setp.cfg versions 
> co-exist?

I think Build/ is the right place.

> Should we put the Win32 one under the Win32 directory?

No. Now that everything seems to work with DistUtils I'd like to abandon 
this directory completely.

> That 
> particular directory used to host the old build files that I had cobbled 
> together manually to build python-ldap 1.x. In fact I could also provide 
> the new versions of those, for those folks who are more comfortable with 
> the GUI

No. We should stick with one way which is DistUtils.

> I did have to extend setup.py a bit; I attach the unified diff here.

Hmm, can web apply changes one-by-one? I'd really like to see in the diff 
what was changed.

> In fact, I also think that it's better to put the whole of "ldap" and 
> "ldap.schema" as "packages" (in distutils jargon) rather than inserting 
> every individual file by hand into setup.py as a "module".

I already tried this to avoid DistUtils warning messages. Unfortunately this 
doesn't work with Python versions prior 2.3.

error: build_py: supplying both 'packages' and 'py_modules' options is not 
allowed

> Many 
> more lines seem to have changed but it's just an artefact of having 
> reformatted the whole file to use consistently 4-space tabs everywhere. 

Hmm, I'd like to see every single change...

> Now, what I have is a nice graphical installer of Python-ldap 2.0.0pre14 
> for Python 2.3.

Note that this is the CVS version. There's no release of 2.0.0pre14 yet.

 > I made it install the SASL DLL.

Which version of Cyrus SASL? Is the name 'libsasl' also version dependent 
like on Linux/Unices (sasl vs. sasl2)?

> So, please anyone interested let me know and I'll mail you the setup 
> exe.

Could you please send it to me personally? I will make it available as 
public download with experimental status.

> I'd attach it here but I doubt that it would be very interesting 
> for the majority of the readers of this list.

Glad you didn't... ;-)

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

Michael Str=F6der wrote:

> >BTW Michael, how would you let the different setp.cfg versions co-exis=
t?
> I think Build/ is the right place.=20

Right. I'd create a "Build/win32" dir and put the setup.cfg there.=20
Obviously the main dir should have pointers to let people know they=20
should look into "Build/<platform>".

> We should stick with one way which is DistUtils.

OK. I guess you can zap directory "Win32" from the CVS tree altogether,=20
then.

>> I did have to extend setup.py a bit; I attach the unified diff here.
>
> Hmm, can web apply changes one-by-one? I'd really like to see in the=20
> diff what was changed.

Right. I attach a file where I try to let changes stand out more.
The changes I had to insert are:
1. I needed extra options for the linker; so I added "extra_link_args"=20
to the class definition and passed it to the constructor.
2. I hijacked the "data files" mechanism in Distutils to carry over the=20
Cyrus-SASL DLL. I added "extra_files" to the class definition and passed =

it to setup() as the "data_files" param. I also had to add a loop to=20
process that setting in the setup.cfg.
3. I added the library names I got under Win32 for LDAP (oldap_r) and=20
SASL (libsasl) to the macro-definition logic.

> ... avoid DistUtils warning messages. Unfortunately this doesn't work=20
> with Python versions prior 2.3.
>
> error: build_py: supplying both 'packages' and 'py_modules' options is =

> not allowed=20

Hmmm, this is unfortunate. I wasn't aware of this limitation. I wonder wh=
y?
If so, let's revert to the old style. However, there's one file missing=20
from the manually-built list (ldap/filter.py). Is this intentional?

> Which version of Cyrus SASL?

I got it from their CVS a few days ago; so it must be later than 2.1.2=20
which is the latest source tarball available on their site.
I didn't use 2.1.2 because it has serious problems building on Windows,=20
whereas the CVS version builds like a charm out of the box.

> Is the name 'libsasl' also version dependent like on Linux/Unices=20
> (sasl vs. sasl2)?

It appears not to; in fact, the MSVC project files included with the=20
sources build a DLL called LIBSASL without any indication of the version.=


> Could you please send it to me personally? I will make it available as =

> public download with experimental status.=20

Done. You'll get it in a separate message ;-)

Mauro

Re: Win32 Binaries?

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

Mauro Cicognini wrote:
> Michael Str=F6der wrote:
>=20
>> >BTW Michael, how would you let the different setp.cfg versions co-exi=
st?
>> I think Build/ is the right place.=20
>=20
> Right. I'd create a "Build/win32" dir and put the setup.cfg there.

Already checked in Build/setup.cfg.win32 and Build/setup.cfg.suse-linux a=
nd=20
added it to MANIFEST.in.

> Obviously the main dir should have pointers to let people know they=20
> should look into "Build/<platform>".

Already added comment to INSTALL.

>> We should stick with one way which is DistUtils.
>=20
> OK. I guess you can zap directory "Win32" from the CVS tree altogether,=
=20
> then.

Was never in the normal source distribution anyway.

>>> I did have to extend setup.py a bit; I attach the unified diff here.
>>
>> Hmm, can web apply changes one-by-one? I'd really like to see in the=20
>> diff what was changed.
>=20
> Right. I attach a file where I try to let changes stand out more.

I already checked in your previous diffs. In the end it wasn't that hard =
to=20
figure out what has changed. But just as advice for next time...

> 1. I needed extra options for the linker; so I added "extra_link_args" =

> to the class definition and passed it to the constructor.
> 2. I hijacked the "data files" mechanism in Distutils to carry over the=
=20
> Cyrus-SASL DLL. I added "extra_files" to the class definition and passe=
d=20
> it to setup() as the "data_files" param. I also had to add a loop to=20
> process that setting in the setup.cfg.
> 3. I added the library names I got under Win32 for LDAP (oldap_r) and=20
> SASL (libsasl) to the macro-definition logic.

Noted.

>> error: build_py: supplying both 'packages' and 'py_modules' options is=
=20
>> not allowed=20
>=20
> Hmmm, this is unfortunate. I wasn't aware of this limitation. I wonder =
why?

I wonder why, too. :-/

> If so, let's revert to the old style.

Already done.


> However, there's one file missing=20
> from the manually-built list (ldap/filter.py). Is this intentional?

Ouch! Good catch! Fixed.

I will now test your Win32 build...

Ciao, Michael.