There have been substantial updates to RE24. Please test!
Thanks, Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
There have been substantial updates to RE24. Please test!
The build is littered with warnings
cc -g -I../../include -I../../../r24/include -c -o parse.o ../../../r24/libraries/librewrite/parse.c In file included from ../../../r24/libraries/librewrite/rewrite-int.h:51, from ../../../r24/libraries/librewrite/config.c:22: ../../../r24/include/ldap_pvt_thread.h:37:1: warning: "LDAP_PVT_MUTEX_FIRSTCREATE" redefined In file included from ../../../r24/libraries/librewrite/rewrite-int.h:36, from ../../../r24/libraries/librewrite/config.c:22: ../../../r24/libraries/librewrite/../libldap/ldap-int.h:192:1: warning: this is the location of the previous definition
--On Thursday, January 06, 2011 2:45 PM -0800 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
There have been substantial updates to RE24. Please test!
The build is littered with warnings
cc -g -I../../include -I../../../r24/include -c -o parse.o ../../../r24/libraries/librewrite/parse.c In file included from ../../../r24/libraries/librewrite/rewrite-int.h:51, from ../../../r24/libraries/librewrite/config.c:22: ../../../r24/include/ldap_pvt_thread.h:37:1: warning: "LDAP_PVT_MUTEX_FIRSTCREATE" redefined In file included from ../../../r24/libraries/librewrite/rewrite-int.h:36, from ../../../r24/libraries/librewrite/config.c:22: ../../../r24/libraries/librewrite/../libldap/ldap-int.h:192:1: warning: this is the location of the previous definition
Sounds like some of the ITS#6625 stuff needs more cleanup then.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
Howard Chu hyc@symas.com wrote:
The build is littered with warnings (...) ../../../r24/include/ldap_pvt_thread.h:37:1: warning: "LDAP_PVT_MUTEX_FIRSTCREATE" redefined (...)
Sounds like some of the ITS#6625 stuff needs more cleanup then.
That's why I reopened ITS#5421, noted it as to be resolved in ITS#6625, and tried to start a thread
librewrite & co vs. logging & ldap-int.h http://www.openldap.org/lists/openldap-devel/201011/msg00013.html
with the underlying problem. But a quick work-around should be to #undef LDAP_PVT_MUTEX_FIRSTCREATE before #including ldap-int.h from outside libldap.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/06/2011 11:17 PM, Quanah Gibson-Mount wrote:
There have been substantial updates to RE24. Please test!
On Debian Squeeze, x86_64, db 4.8.30, as well as a similar machine with x86_64 kernel, i386 userspace, db 4.7.25, all tests run ok.
On a different host, RHEL5, x86_64, db 4.7.25 every test ends with a slapd segfault that gets ignored:
Test succeeded
./scripts/test016-subref: line 195: 19266 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1
./scripts/test016-subref completed OK for hdb.
... ./scripts/test018-syncreplication-persist: line 538: 19907 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING
$LOG1 2>&1
./scripts/test018-syncreplication-persist: line 538: 20040 Segmentation fault (core dumped) $SLAPD -f $CONF4 -h $URI4 -d $LVL $TIMING
$LOG4 2>&1
./scripts/test018-syncreplication-persist completed OK for hdb.
... ./scripts/test058-syncrepl-asymmetric: line 2335: 9383 Segmentation fault (core dumped) $SLAPD -F slapd.d -h $URI1 -d $LVL $TIMING
$LOG1 2>&1 (wd: /tmp/openldap-2.4.24rc2/tests/testrun/smc)
...
configure was run with the following params: CPPFLAGS=-I/opt/ds-1.0/include/ LDFLAGS="-Wl,-rpath=/opt/ds-1.0/lib64 - -L/opt/ds-1.0/lib64" ./configure --enable-overlays --enable-backends - --disable-ndb && make depend && make -j4 && make test
Where should I look for further info?
Every time I compile slapd with "--enable-modules" but without "--enable-dynamic", I get symbol resolution errors about libldap functions on every machine aborting the slapd process. Is it expected with this ./configure parameter combination? If so, shouldn't "--enable-modules" imply "--enable-dynamic"?
I have asked this question several times already on openldap-technical/#openldap, but have never received any response.
Regards, Ondrej Kuznik
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/06/2011 11:17 PM, Quanah Gibson-Mount wrote:
There have been substantial updates to RE24. Please test!
On Debian Squeeze, x86_64, db 4.8.30, as well as a similar machine with x86_64 kernel, i386 userspace, db 4.7.25, all tests run ok.
On a different host, RHEL5, x86_64, db 4.7.25 every test ends with a slapd segfault that gets ignored:
Test succeeded
./scripts/test016-subref: line 195: 19266 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING>$LOG1 2>&1
./scripts/test016-subref completed OK for hdb.
... ./scripts/test018-syncreplication-persist: line 538: 19907 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING
$LOG1 2>&1
./scripts/test018-syncreplication-persist: line 538: 20040 Segmentation fault (core dumped) $SLAPD -f $CONF4 -h $URI4 -d $LVL $TIMING
$LOG4 2>&1
./scripts/test018-syncreplication-persist completed OK for hdb.
... ./scripts/test058-syncrepl-asymmetric: line 2335: 9383 Segmentation fault (core dumped) $SLAPD -F slapd.d -h $URI1 -d $LVL $TIMING
$LOG1 2>&1 (wd: /tmp/openldap-2.4.24rc2/tests/testrun/smc)
...
configure was run with the following params: CPPFLAGS=-I/opt/ds-1.0/include/ LDFLAGS="-Wl,-rpath=/opt/ds-1.0/lib64
- -L/opt/ds-1.0/lib64" ./configure --enable-overlays --enable-backends
- --disable-ndb&& make depend&& make -j4&& make test
Where should I look for further info?
Enable core dumps and examine the core files with gdb.
Every time I compile slapd with "--enable-modules" but without "--enable-dynamic", I get symbol resolution errors about libldap functions on every machine aborting the slapd process. Is it expected with this ./configure parameter combination? If so, shouldn't "--enable-modules" imply "--enable-dynamic"?
It's a known issue, but it only shows up with some versions of libtool (and not others).
I have asked this question several times already on openldap-technical/#openldap, but have never received any response.
The FAQ-o-Matic has stock answers for core dump issues, so questions of this nature rarely merit a direct response.
Howard Chu wrote:
Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/06/2011 11:17 PM, Quanah Gibson-Mount wrote:
There have been substantial updates to RE24. Please test!
On Debian Squeeze, x86_64, db 4.8.30, as well as a similar machine with x86_64 kernel, i386 userspace, db 4.7.25, all tests run ok.
On a different host, RHEL5, x86_64, db 4.7.25 every test ends with a slapd segfault that gets ignored:
> Test succeeded
./scripts/test016-subref: line 195: 19266 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING>$LOG1 2>&1
> ./scripts/test016-subref completed OK for hdb.
... ./scripts/test018-syncreplication-persist: line 538: 19907 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING
$LOG1 2>&1
./scripts/test018-syncreplication-persist: line 538: 20040 Segmentation fault (core dumped) $SLAPD -f $CONF4 -h $URI4 -d $LVL $TIMING
$LOG4 2>&1
> ./scripts/test018-syncreplication-persist completed OK for hdb.
... ./scripts/test058-syncrepl-asymmetric: line 2335: 9383 Segmentation fault (core dumped) $SLAPD -F slapd.d -h $URI1 -d $LVL $TIMING
$LOG1 2>&1 (wd: /tmp/openldap-2.4.24rc2/tests/testrun/smc)
...
configure was run with the following params: CPPFLAGS=-I/opt/ds-1.0/include/ LDFLAGS="-Wl,-rpath=/opt/ds-1.0/lib64
- -L/opt/ds-1.0/lib64" ./configure --enable-overlays --enable-backends
- --disable-ndb&& make depend&& make -j4&& make test
Where should I look for further info?
Enable core dumps and examine the core files with gdb.
Every time I compile slapd with "--enable-modules" but without "--enable-dynamic", I get symbol resolution errors about libldap functions on every machine aborting the slapd process. Is it expected with this ./configure parameter combination? If so, shouldn't "--enable-modules" imply "--enable-dynamic"?
It's a known issue, but it only shows up with some versions of libtool (and not others).
I have asked this question several times already on openldap-technical/#openldap, but have never received any response.
The FAQ-o-Matic has stock answers for core dump issues, so questions of this nature rarely merit a direct response.
PS: This is the -devel list. You're expected to know what's in the FAQ already.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2011 01:02 PM, Howard Chu wrote:
Howard Chu wrote:
Ondrej Kuznik wrote:
On 01/06/2011 11:17 PM, Quanah Gibson-Mount wrote:
There have been substantial updates to RE24. Please test!
On a different host, RHEL5, x86_64, db 4.7.25 every test ends with a slapd segfault that gets ignored:
Where should I look for further info?
Enable core dumps and examine the core files with gdb.
Yeah, I did that in the meantime, seeing strange backtraces in gdb. I found out later that the fault was in my environment, as I accidentaly let slapd use different libldap than the one it was compiled with. Running with libldap from this testing call made all tests pass OK.
Every time I compile slapd with "--enable-modules" but without "--enable-dynamic", I get symbol resolution errors about libldap functions on every machine aborting the slapd process. Is it expected with this ./configure parameter combination? If so, shouldn't "--enable-modules" imply "--enable-dynamic"?
It's a known issue, but it only shows up with some versions of libtool (and not others).
I have asked this question several times already on openldap-technical/#openldap, but have never received any response.
The FAQ-o-Matic has stock answers for core dump issues, so questions of this nature rarely merit a direct response.
This was not a segfault/core dump issue, that I more or less know what to do with(*), but symbol resolution issue and I believe I have pointed that out then. Also, I did search the FAQ, ITS and mailing lists and concluded that it was not known. However, as you have told me now that this issue is known, it does not matter anymore, so thanks for the info.
(*) well mostly, I've never really investigated a dump where the stack seemed corrupted
BTW: the search at http://www.openldap.org/lists/$LIST/ can't seem to find anything for any query.
PS: This is the -devel list. You're expected to know what's in the FAQ already.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Am Thu, 06 Jan 2011 14:17:13 -0800 schrieb Quanah Gibson-Mount quanah@zimbra.com:
There have been substantial updates to RE24. Please test!
I get a Warning and an db Error:
checking arpa/nameser.h usability... no checking arpa/nameser.h presence... yes configure: WARNING: arpa/nameser.h: present but cannot be compiled configure: WARNING: arpa/nameser.h: check for missing prerequisite headers? configure: WARNING: arpa/nameser.h: see the Autoconf documentation configure: WARNING: arpa/nameser.h: section "Present But Cannot Be Compiled" configure: WARNING: arpa/nameser.h: proceeding with the compiler's result configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to http://www.openldap.org/its/ ## configure: WARNING: ## --------------------------------------------- ## checking for arpa/nameser.h... no
from arpa/namser.h
#define __NAMESER 19991006
and an db Error:
checking db.h usability... no checking db.h presence... yes configure: WARNING: db.h: present but cannot be compiled configure: WARNING: db.h: check for missing prerequisite headers? configure: WARNING: db.h: see the Autoconf documentation configure: WARNING: db.h: section "Present But Cannot Be Compiled" configure: WARNING: db.h: proceeding with the compiler's result configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to http://www.openldap.org/its/ ## configure: WARNING: ## --------------------------------------------- ## checking for db.h... no
BerkelyDB is:
#define DB_VERSION_MAJOR 4 #define DB_VERSION_MINOR 8 #define DB_VERSION_PATCH 26 #define DB_VERSION_STRING "Berkeley DB 4.8.26: (December 18, 2009)"
-Dieter
Dieter Kluenter wrote:
Am Thu, 06 Jan 2011 14:17:13 -0800 schrieb Quanah Gibson-Mountquanah@zimbra.com:
There have been substantial updates to RE24. Please test!
I get a Warning and an db Error:
Something is probably wrong with your compiler. Certainly the check for arpa/nameser.h has not changed in the configure script in several years.
Does 2.4.23 configure script give this same warning?
checking arpa/nameser.h usability... no checking arpa/nameser.h presence... yes configure: WARNING: arpa/nameser.h: present but cannot be compiled configure: WARNING: arpa/nameser.h: check for missing prerequisite headers? configure: WARNING: arpa/nameser.h: see the Autoconf documentation configure: WARNING: arpa/nameser.h: section "Present But Cannot Be Compiled" configure: WARNING: arpa/nameser.h: proceeding with the compiler's result configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this tohttp://www.openldap.org/its/ ## configure: WARNING: ## --------------------------------------------- ## checking for arpa/nameser.h... no
from arpa/namser.h
#define __NAMESER 19991006
and an db Error:
checking db.h usability... no checking db.h presence... yes configure: WARNING: db.h: present but cannot be compiled configure: WARNING: db.h: check for missing prerequisite headers? configure: WARNING: db.h: see the Autoconf documentation configure: WARNING: db.h: section "Present But Cannot Be Compiled" configure: WARNING: db.h: proceeding with the compiler's result configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this tohttp://www.openldap.org/its/ ## configure: WARNING: ## --------------------------------------------- ## checking for db.h... no
BerkelyDB is:
#define DB_VERSION_MAJOR 4 #define DB_VERSION_MINOR 8 #define DB_VERSION_PATCH 26 #define DB_VERSION_STRING "Berkeley DB 4.8.26: (December 18, 2009)"
-Dieter
Am Sun, 09 Jan 2011 00:16:33 -0800 schrieb Howard Chu hyc@symas.com:
Dieter Kluenter wrote:
Am Thu, 06 Jan 2011 14:17:13 -0800 schrieb Quanah Gibson-Mountquanah@zimbra.com:
There have been substantial updates to RE24. Please test!
I get a Warning and an db Error:
Something is probably wrong with your compiler. Certainly the check for arpa/nameser.h has not changed in the configure script in several years.
It's been my script, which included the compiler options -ansi and -pedantic (which I didn't notice), after removing this options, compilation finished successful.
-Dieter
-
Aaron Richton -
Dieter Kluenter -
Hallvard B Furuseth -
Howard Chu -
Ondrej Kuznik -
Quanah Gibson-Mount