openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#5930) Problem while making the build
by quanah＠zimbra.com 09 Feb '09

09 Feb '09

--On Monday, February 09, 2009 7:44 AM +0000 bhupi.iit(a)gmail.com wrote: > Full_Name: Bhupinder > Version: 2.4.11 > OS: Solaris SunOS.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (149.77.167.165) > > > setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB/lib > setenv CPPFLAGS -I/usr/local/BerkeleyDB/include/ > > ./configure > make depend > make > > while 'mak'ing i get the following error. > .. > .. > .. > /bin/sh ../..//libtool --mode=compile cc -g -I../../include > -I../../include -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c > tls.c cc -g -I../../include -I../../include > -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c tls.c -KPIC -DPIC -o > .libs/tls.o > "tls.c", line 102: syntax error before or at: gnutls_kx_algorithm_t > "tls.c", line 112: syntax error before or at: typedef > "tls.c", line 114: syntax error before or at: > gnutls_certificate_credentials_t "tls.c", line 127: syntax error before > or at: typedef > "tls.c", line 128: syntax error before or at: tls_ctx > "tls.c", line 189: member cannot be function: ldap_pvt_tls_ctx_free > "tls.c", line 189: warning: syntax requires ";" after last struct/union > member "tls.c", line 189: syntax error before or at: { > "tls.c", line 191: syntax error before or at: tls_ctx > "tls.c", line 211: member cannot be function: tls_ctx_new > "tls.c", line 211: warning: syntax requires ";" after last struct/union > member "tls.c", line 211: syntax error before or at: { > "tls.c", line 230: syntax error before or at: * > "tls.c", line 231: member cannot be function: tls_ctx_ref > "tls.c", line 231: warning: syntax requires ";" after last struct/union > member "tls.c", line 242: warning: syntax requires ";" after last > struct/union member "tls.c", line 262: warning: syntax requires ";" after > last struct/union member "tls.c", line 275: syntax error before or at: * > "tls.c", line 276: member cannot be function: tls_session_free > "tls.c", line 276: warning: syntax requires ";" after last struct/union > member "tls.c", line 285: syntax error before or at: * > "tls.c", line 285: warning: undefined or missing type for: char > "tls.c", line 286: member cannot be function: tls_parse_ciphers > "tls.c", line 286: warning: syntax requires ";" after last struct/union > member "tls.c", line 289: warning: syntax requires ";" after last > struct/union member "tls.c", line 289: syntax error before or at: = > "tls.c", line 292: syntax error before or at: num > "tls.c", line 314: warning: syntax requires ";" after last struct/union > member "tls.c", line 350: zero-sized struct/union > "tls.c", line 352: warning: old-style declaration or incorrect type for: > ptr "tls.c", line 352: warning: old-style declaration or incorrect type > for: len "tls.c", line 352: warning: syntax error: empty declaration > "tls.c", line 353: warning: old-style declaration or incorrect type for: > end "tls.c", line 354: undefined symbol: nkx > "tls.c", line 354: can not declare variably modified type at file scope > "tls.c", line 354: warning: old-style declaration or incorrect type for: > kx "tls.c", line 354: warning: {}-enclosed initializer required > "tls.c", line 354: too many array initializers > "tls.c", line 354: warning: variable length array can not be initialized: > kx "tls.c", line 355: undefined symbol: ncipher > "tls.c", line 355: can not declare variably modified type at file scope > "tls.c", line 355: warning: old-style declaration or incorrect type for: > cipher "tls.c", line 355: warning: {}-enclosed initializer required > "tls.c", line 355: too many array initializers > "tls.c", line 355: warning: variable length array can not be initialized: > cipher > "tls.c", line 356: undefined symbol: nmac > "tls.c", line 356: can not declare variably modified type at file scope > "tls.c", line 356: warning: old-style declaration or incorrect type for: > mac "tls.c", line 356: warning: {}-enclosed initializer required > "tls.c", line 356: too many array initializers > "tls.c", line 356: warning: variable length array can not be initialized: > mac "tls.c", line 357: warning: old-style declaration or incorrect type > for: ctx "tls.c", line 357: syntax error before or at: -> > "tls.c", line 357: warning: old-style declaration or incorrect type for: > kx_list > "tls.c", line 357: warning: improper pointer/integer combination: op "=" > "tls.c", line 358: warning: old-style declaration or incorrect type for: > ctx "tls.c", line 358: syntax error before or at: -> > "tls.c", line 358: warning: old-style declaration or incorrect type for: > cipher_list > "tls.c", line 358: warning: improper pointer/integer combination: op "=" > "tls.c", line 359: warning: old-style declaration or incorrect type for: > ctx "tls.c", line 359: syntax error before or at: -> > "tls.c", line 359: warning: old-style declaration or incorrect type for: > mac_list > "tls.c", line 359: warning: improper pointer/integer combination: op "=" > "tls.c", line 360: syntax error before or at: return > "tls.c", line 360: warning: syntax error: empty declaration > "tls.c", line 532: cannot recover from previous errors > cc: acomp failed for tls.c > make[2]: *** [tls.lo] Error 1 > make[2]: Leaving directory `~openldap/openldap-2.4.11/libraries/libldap' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `~/openldap/openldap-2.4.11/libraries' > make: *** [all-common] Error 1 > > > > Please let me know if i'm doing something wrong here. Looks like it can't find your GnuTLS headers/libs, at a guess. In any case, this isn't an OpenLDAP bug. Please use openldap-software for further help with building OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

ando(a)sys-net.it wrote: > Slapd in HEAD no longer crashes when receiving intermediate response. > It rather complains about an unsupported response message. I'm now > working at correctly handling it. This won't probably be as easy as I expected: back-meta does not check, parse or return entry controls. This needs to be fixed as well. I notice that back-ldap and back-meta use ldap_first_entry() to parse the entry. Syncrepl client-side code uses a ldap_get_entry_controls() and explicit entry parsing. Probably we need to abstract what syncrepl does in a new libldap call that parses an entry and its controls, and use it as appropriate. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Need bug list for openldap-2.2.24 release.
by kalyan tej 09 Feb '09

09 Feb '09

Hi Folks, I am new to openldap ,I'd like to know the list of software bugs in openldap-2.2.24 release. I chose openldap-2.2.24 because my libc version is 2.3.3.It would be of great help to me if someone can provide me with the major list of bugs in the mentioned release and/or fixes . Thanks in advance, -Kalyan Tej

2 1

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Slapd in HEAD no longer crashes when receiving intermediate response. It rather complains about an unsupported response message. I'm now working at correctly handling it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

ali.pouya(a)free.fr wrote: > I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd > through an intermediate back-meta slapd in order tu use its RWM features. > The search entries are propagated without problem. But back-meta crashes each > time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider > reproducing the following message : > > read1msg: ld 0x9f29550 msgid 2 message type intermediate > slapd: search.c:1460: meta_back_search: Assertion `0' failed. > Abandon Back-beta (and probably back-ldap) need to be able to recognize intermediate response messages, as they are part of the protocol. Probably, it would be a good idea to detect unrecognized response messages and handle them nicely. > I think this would be a useful feature to be able to make replicas that are > different from the master. > May be if this response time is propagated as is this type of synchronization > will be possible ? I'd notice that this type of operation might be less than ideal, since a proxied refreshAndPersist operation will keep one thread of the proxy busy all times waiting for further responses. > I am aware that connection to more thant one targets through back-meta may be > meaningless. In that case you could use back-ldap with slapo-rwm. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5933) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Full_Name: Ali Pouya Version: 2.4.13 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.3) I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd through an intermediate back-meta slapd in order tu use its RWM features. The search entries are propagated without problem. But back-meta crashes each time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider reproducing the following message : read1msg: ld 0x9f29550 msgid 2 message type intermediate slapd: search.c:1460: meta_back_search: Assertion `0' failed. Abandon I think this would be a useful feature to be able to make replicas that are different from the master. May be if this response time is propagated as is this type of synchronization will be possible ? I am aware that connection to more thant one targets through back-meta may be meaningless. Thanks for your help Best Redgards Ali Pouya

1 0

(ITS#5932) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Full_Name: Ali Pouya Version: 2.4.13 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd through an intermediate back-meta slapd in order tu use its RWM features. The search entries are propagated without problem. But back-meta crashes each time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider reproducing the following message : read1msg: ld 0x9f29550 msgid 2 message type intermediate slapd: search.c:1460: meta_back_search: Assertion `0' failed. Abandon I think this would be a useful feature to be able to make replicas that are different from the master. May be if this response time is propagated as is this type of synchronization will be possible ? I am aware that connection to more thant one targets through back-meta may be meaningless. Thanks for your help Best Redgards Ali Pouya

1 0

(ITS#5931) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 09 Feb '09

09 Feb '09

hyc(a)symas.com wrote: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>>> Seems to me we need to reinstate those commands. >>> Fixed now in HEAD >> Didn't help. But I'm not sure it was necessary anyway - after all it >> did find the libraries when I did not set LDPATH, even though there >> were no symlinks. Something is being quite magical. >> > Eh. I'd forgotten. The libtool script generates a wrapper script for each > binary that sets LD_LIBRARY_PATH already. So really we should remove the > LD_LIBRARY_PATH export from scripts/defines.sh. > > And that means your problem is a libtool problem. I played with this a bit more. The situation is this: The ELF linker doesn't store the absolute pathnames of dependent dynamic libraries, so it relies entirely on compiled-in runpaths and environment runpaths. Our default invocations of libtool never supply a runpath. Since you're adding one explicitly to your build, without any other settings, your runpath is the only one in effect. Since you're setting both -L and -rpath, your binaries will be linked and executed against your installed libs, regardless of what the libtool wrapper script does. If you want this to work you'll have to provide both the build directory and your installed directory in your -rpath. The symlinks would then help a little, because you only need to set one build rpath instead of 3. Go ahead and restore the build rules in your source tree to set the symlinks if you want them. At the moment it looks like they're not generally useful, and I'm tired of committing/reverting, so I'm not touching those files any more today. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 09 Feb '09

09 Feb '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> Seems to me we need to reinstate those commands. >> Fixed now in HEAD > > Didn't help. But I'm not sure it was necessary anyway - after all it > did find the libraries when I did not set LDPATH, even though there > were no symlinks. Something is being quite magical. > Eh. I'd forgotten. The libtool script generates a wrapper script for each binary that sets LD_LIBRARY_PATH already. So really we should remove the LD_LIBRARY_PATH export from scripts/defines.sh. And that means your problem is a libtool problem. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs