GNOME Bugzilla – Bug 384303
[build] reference to unknown LDAP_CONTROL_PAGEDRESULTS
Last modified: 2007-03-12 20:50:10 UTC
e-book-backend-gal.c: In function 'generate_cache': e-book-backend-gal.c:1903: error: 'LDAP_CONTROL_PAGEDRESULTS' undeclared (first use in this function) e-book-backend-gal.c:1903: error: (Each undeclared identifier is reported only once e-book-backend-gal.c:1903: error: for each function it appears in.) -- http://jhbuild.bxlug.be/builds/2006-12-10-0002/logs/evolution-exchange/#build This is on Debian, using headers from OpenLDAP 2.1.30. For reference, declared LDAP_CONTROL_* constants are: #define LDAP_CONTROL_VALUESRETURNFILTER "1.2.826.0.1.334810.2.3" #define LDAP_CONTROL_SUBENTRIES "1.3.6.1.4.1.4203.1.10.1" #define LDAP_CONTROL_NOOP "1.3.6.1.4.1.4203.1.10.2" #define LDAP_CONTROL_MANAGEDSAIT "2.16.840.1.113730.3.4.2" #define LDAP_CONTROL_PROXY_AUTHZ "2.16.840.1.113730.3.4.18" #define LDAP_CONTROL_SORTREQUEST "1.2.840.113556.1.4.473" #define LDAP_CONTROL_SORTRESPONSE "1.2.840.113556.1.4.474" #define LDAP_CONTROL_VLVREQUEST "2.16.840.1.113730.3.4.9" #define LDAP_CONTROL_VLVRESPONSE "2.16.840.1.113730.3.4.10" #define LDAP_CONTROL_NOT_FOUND 0x5d /* draft-ietf-ldap-c-api-xx */
devashish: ping.
evolution-exchange 2.9.3 doesn't build on Ubuntu feisty neither because of that
Devashish, Sebastien: This post from the GARNOME mailing list might help. http://mail.gnome.org/archives/garnome-list/2007-January/msg00052.html > The culprit is Ubuntu LDAP2 package version (2.1.30) wicht doesn't have > that variable declared. There is a 2.2.x version but only the runtime > files are available and no 'dev' one. Silently introduced a new / stricter dependency, without updating configure.in?
There is a debian bug from 2005 <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332693">#332693</a> open on this, but it doesn't seem that anyone is updating it. I didn't find anything on launchpad about this issue on ubuntu. I've added myself cc to this debian bug, but might it be possible to just add ldap client libraries to garnome? As it seems that debian/ubuntu maintainers are not going to update this anytime soon. -- Bryan Hundven
I'm seeing this too at http://jhbuild.bxlug.be/builds/2007-02-09-0003/logs/evolution-exchange/#build
Created attachment 82672 [details] Log of build I use Ubuntu Feisty and build GNOME with garnome 2.17.92. And build evolution-exchange. Atach my log.
And NOT build. Pliss change status of UNCONFIRMED to NEW. Thanks.
(In reply to comment #3) > Devashish, Sebastien: This post from the GARNOME mailing list might help. > > http://mail.gnome.org/archives/garnome-list/2007-January/msg00052.html > > The culprit is Ubuntu LDAP2 package version (2.1.30) wicht doesn't have > > that variable declared. There is a 2.2.x version but only the runtime > > files are available and no 'dev' one. > > Silently introduced a new / stricter dependency, without updating configure.in? Howto update configure.in?
Created attachment 83814 [details] [review] Disable paged results when OpenLDAP support isn't available Here's a patch disabling the PAGED_RESULTS LDAPControl when it's not available in the ldap lib. You might want to output a warning if pagedResults is set but PAGED_RESULTS aren't supported.
FYI, It seems Fedora Core 7 and OpenSuse track OpenLDAP 2.3, so are not affected by this problem, but Ubuntu and Debian still build against libldap2-dev 2.2.
AIUI it's a licesning issue; from the slapd README.Debian: ++ TLS/SSL support This version of the OpenLDAP server and its library is compiled with the OpenSSL library as supported by the upstream sources. Other packages are not allowed to link against this version of OpenLDAP (or rather its library) but this way we have a working OpenLDAP server. Client packages will have to continue using the old libldap2 package for ldap access as that version is linked against GNUTLS to allow for example dynamic linking into Samba. We are working on updating that GNUTLS patch for OpenLDAP 2.2 and getting it into the upstream package. When that is accomplished the old libldap2 packages will disappear and OpenLDAP 2.2 will be used together with GNUTLS in Debian.
(In reply to comment #9) > Created an attachment (id=83814) [edit] > Disable paged results when OpenLDAP support isn't available > > Here's a patch disabling the PAGED_RESULTS LDAPControl when it's not available > in the ldap lib. Im sure that this would go pass the warning. But the caching wont be complete. I think that you should disable at configure.in if the version don't match and disable caching at all, so that an inconsistent state is never given to a user. > > You might want to output a warning if pagedResults is set but PAGED_RESULTS > aren't supported. >
Can you clarify what you mean by "disabling the caching"? I have zero knowledge on evolution-exchange, so I'm afraid I can't provide a patch which requires knowledge of how the application logic / architecture, unfortunately. Still, if it's about /disabling/ code only, I suppose it's not even necessary to add configure.in tests, #ifdefs are enough; or do you mean outputting a warning at configure time when such support is missing?
(In reply to comment #13) > Can you clarify what you mean by "disabling the caching"? GAL didnt have caching initially. This patch enabled that. Have a way to disable it on conditional basis. If you see the commit logs, it can help u. > > I have zero knowledge on evolution-exchange, so I'm afraid I can't provide a > patch which requires knowledge of how the application logic / architecture, > unfortunately. > > Still, if it's about /disabling/ code only, I suppose it's not even necessary > to add configure.in tests, #ifdefs are enough; or do you mean outputting a > warning at configure time when such support is missing? Sure. >
I checked the commit of the line adding 'LDAP_CONTROL_PAGEDRESULTS', and it's very large and intrusive. It seems to me LDAP_CONTROL_PAGEDRESULTS is an optional setting for the query, but it still seems possible to build a cache without it; is this incorrect?
(In reply to comment #15) > I checked the commit of the line adding 'LDAP_CONTROL_PAGEDRESULTS', and it's > very large and intrusive. > > It seems to me LDAP_CONTROL_PAGEDRESULTS is an optional setting for the query, > but it still seems possible to build a cache without it; is this incorrect? > It will get just few entries and not all. Paged results get the next pages also.
I'm afraid I'm not intimate enough with OpenLDAP and Evolution Exchange to work on this, so I'll leave it to someone actually using evolution-exchange.
Created attachment 83957 [details] [review] Proposed patch This should avoid the compilation error and returns error when the store is offline and also avoid crashes if the cache is NULL
Varadha, review?
Created attachment 83961 [details] [review] Updated patch Fixes a typo in the prev patch. Sorry for the spam.
Srag: I suggest that you separate the build fix and the other fixes to avoid the crashes and handle offline-store. If I understand your changes - caching is disabled totally if LDAP_CONTROL_PAGEDRESULTS is undefined. In which case, the configure warning must also be included in your patch, also disabling cache related features/gconf options etc.
Created attachment 84055 [details] [review] Additional patch Patch for configure.in
This gives out a warning at configure time on disabling GAL caching if paged results not found. I dont think, anything to be done at gconf for this. The initial patch to add caching did nothing and I dont have to reverse anything here.
It compiles for me with the patches in garnome. I'll check gconf while it's running after the rest of this build to let you know if anything needs to be done for gconf as well.
Patch committed to SVN Trunk.