Bug Tracker item #3176215, was opened at 2011-02-09 07:18 Message generated for change (Comment added) made by sbajic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3176215&group_id=250683
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Julien Valroff (valroff) Assigned to: Stevan Bajic (sbajic) Summary: Fails to compile with LDAP support for ExernalLookup Initial Comment: Hi, A user of the Debian package has just informed me that the ExternalLookup was built without LDAP support. When checking the build logs, I can see: [...] Selecting previously deselected package libldap-2.4-2. Unpacking libldap-2.4-2 (from .../libldap-2.4-2_2.4.23-7_amd64.deb) ... [...] checking whether to enable external lookup support... yes checking lber.h usability... yes checking lber.h presence... yes checking for lber.h... yes checking ldap.h usability... yes checking ldap.h presence... yes checking for ldap.h... yes checking for ber_alloc in -llber... yes checking for ldap_init in -lldap... yes checking for OpenLDAP version >= 2.2.0... no checking whether to enable LDAP support in external lookup... no As far as I could check, the external_lookup.m4 part responisble for this check wasn't changed recently, so this might also be a problem particular to Debian, but I doubt though. Might be linked to the patch I provided to reduce the number of unused dependencies, but I cannot find what could cause this behaviour. Any help would be much appreciated, I'd be happy to test any patch proposal. Cheers, Julien ---------------------------------------------------------------------- >Comment By: Stevan Bajic (sbajic) Date: 2011-02-09 21:11 Message: Good to read that it is working. So the m4 is okay now? If the LDAP support is not working properly after that fix with the m4 file then something in the ExtLookup module is not properly working and this is then more Hugos area to make a fix (Okay, okay. The m4 was/is Hogos area too but fixing a non working m4 is easier for me than digging into ExtLookup code). I will commit now this change since everything beyond that point would anyway be another bug and should be handled in a separate bug report. ---------------------------------------------------------------------- Comment By: Julien Valroff (valroff) Date: 2011-02-09 19:07 Message: Thank you very much Stevan for your quick answer. It seems the patch fixes the issue, as expected: checking whether to enable external lookup support... yes checking lber.h usability... yes checking lber.h presence... yes checking for lber.h... yes checking ldap.h usability... yes checking ldap.h presence... yes checking for ldap.h... yes checking for ber_alloc in -llber... yes checking for ldap_init in -lldap... yes checking for OpenLDAP version >= 2.2.0... yes checking whether to enable LDAP support in external lookup... yes I'll build packages for the user who had suffered the issue so that he can check LDAP support is ok on his side. Cheers, Julien ---------------------------------------------------------------------- Comment By: Stevan Bajic (sbajic) Date: 2011-02-09 18:53 Message: Hello Julien, the patch from last November is not the problem. If you ask me then the way how the m4 is evaluating the OpenLDAP version is not the way it should be. I have quickly made a patch for the m4 file that should fix the problem. Can you check and tell me if the problem is fixed with the patch? -- Kind Regards from Switzerland, Stevan Bajić ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3176215&group_id=250683 ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
