Full_Name: Volkov Serge Version: 2.0.11; 2.0.12 OS: Linux (ALTLinux) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.186.223.229) Hello. When I configure with the next options i have core dumped with "make test" Sorry for Russian messages output, but system configure with Russian locale/ Installation procces is #autoheader #autoconf #env CPPFLAGS="-DLDAP_DEBUG" FFLAGS="-pipe -Wall -O2 -fexpensive-optimizations -march=i586 -mcpu=i686" CXXFLAGS="-pipe -Wall -O2 -fexpensive-optimizations -march=i586 -mcpu=i686" CFLAGS="-pipe -Wall -O2 -fexpensive-optimizations -march=i586 -mcpu=i686" ./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --without-included-gettext --enable-passwd --enable-shell --enable-wrappers --disable-rlookups --without-kerberos --datadir=/usr/share/openldap --libexecdir=/usr/sbin --localstatedir=/var/run --enable-shared --enable-static --disable-ipv6 --with-readline --with-threads --enable-slapd --enable-crypt --enable-syslog --enable-proctitle --enable-ldbm --enable-debug #make depend #make #make test make test cd tests; make test make[1]: ���� � ������� `/home/vserge/test/openldap-2.0.12/tests' ln: `./data': ������ ���������� �������� make[1]: [test-ldbm] ������ 1 (������������) ln: `./schema': ���� ���������� make[1]: [test-ldbm] ������ 1 (������������) Initiating LDAP tests for LDBM... >>>>> Executing all LDAP tests... >>>>> Test Directory: . >>>>> Backend: ldbm >>>>> Starting test000-rootdse ... running defines.sh . ldbm Datadir is ./data Cleaning up in ./test-db... Starting slapd on TCP/IP port 9009... Using ldapsearch to retrieve all the entries... ./scripts/test000-rootdse: line 35: 14976 Segmentation fault (core dumped) $SLAPD -f $SCHEMACONF -h $MASTERURI -d $LVL $TIMING >$MASTERLOG 2>&1 ./scripts/test000-rootdse: line 35: 14977 Segmentation fault (core dumped) $LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 ./scripts/test000-rootdse: line 35: 14978 Segmentation fault (core dumped) $LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 ./scripts/test000-rootdse: line 35: 14979 Segmentation fault (core dumped) $LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 ./scripts/test000-rootdse: line 35: 14980 Segmentation fault (core dumped) $LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 ./scripts/test000-rootdse: line 35: 14981 Segmentation fault (core dumped) $LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 ./scripts/test000-rootdse: line 35: 14982 Segmentation fault (core dumped) $LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 ./scripts/test000-rootdse: kill: (14976) - No such pid >>>>> Test failed >>>>> ./scripts/test000-rootdse failed (exit 139) make[1]: *** [test-ldbm] ������ 139 make[1]: ����� �� ������� `/home/vserge/test/openldap-2.0.12/tests' make: *** [test] ������ 2 When I change in configure.in lines from : dnl ---------------------------------------------------------------- dnl PF_INET6 support requires getaddrinfo and INET6_ADDRSTRLEN dnl PF_LOCAL may use getaddrinfo in available AC_CHECK_FUNCS( inet_ntop ) to : dnl ---------------------------------------------------------------- dnl PF_INET6 support requires getaddrinfo and INET6_ADDRSTRLEN dnl PF_LOCAL may use getaddrinfo in available AC_CHECK_FUNCS( getaddrinfo inet_ntop ) Tests is OK.
2.0.11 and .12 appears to be as you recommend. That is, include getaddrinfo in that AC_CHECK_FUNCS call. Also retest with the provided configure script. At 12:37 AM 2001-09-03, vserge@menatepspb.msk.ru wrote: >Full_Name: Volkov Serge >Version: 2.0.11; 2.0.12 >OS: Linux (ALTLinux) >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (194.186.223.229) > > >Hello. > >When I configure with the next options i have core dumped with "make test" >Sorry for Russian messages output, but system configure with Russian locale/ >Installation procces is >#autoheader >#autoconf >#env CPPFLAGS="-DLDAP_DEBUG" FFLAGS="-pipe -Wall -O2 -fexpensive-optimizations >-march=i586 -mcpu=i686" CXXFLAGS="-pipe -Wall -O2 -fexpensive-optimizations >-march=i586 -mcpu=i686" CFLAGS="-pipe -Wall -O2 -fexpensive-optimizations >-march=i586 -mcpu=i686" ./configure --prefix=/usr --exec-prefix=/usr >--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share >--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib >--localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man >--infodir=/usr/share/info --without-included-gettext --enable-passwd >--enable-shell --enable-wrappers --disable-rlookups --without-kerberos >--datadir=/usr/share/openldap --libexecdir=/usr/sbin --localstatedir=/var/run >--enable-shared --enable-static --disable-ipv6 --with-readline --with-threads >--enable-slapd --enable-crypt --enable-syslog --enable-proctitle --enable-ldbm >--enable-debug >#make depend >#make >#make test > make test >cd tests; make test >make[1]: ÷ÈÏÄ × ËÁÔÁÌÏÇ `/home/vserge/test/openldap-2.0.12/tests' >ln: `./data': ÏÛÉÂËÁ ÐÅÒÅÚÁÐÉÓÉ ËÁÔÁÌÏÇÁ >make[1]: [test-ldbm] ïÛÉÂËÁ 1 (ÉÇÎÏÒÉÒÏ×ÁÎÁ) >ln: `./schema': æÁÊÌ ÓÕÝÅÓÔ×ÕÅÔ >make[1]: [test-ldbm] ïÛÉÂËÁ 1 (ÉÇÎÏÒÉÒÏ×ÁÎÁ) >Initiating LDAP tests for LDBM... >>>>>> Executing all LDAP tests... >>>>>> Test Directory: . >>>>>> Backend: ldbm >>>>>> Starting test000-rootdse ... >running defines.sh . ldbm >Datadir is ./data >Cleaning up in ./test-db... >Starting slapd on TCP/IP port 9009... >Using ldapsearch to retrieve all the entries... >./scripts/test000-rootdse: line 35: 14976 Segmentation fault (core dumped) >$SLAPD -f $SCHEMACONF -h $MASTERURI -d $LVL $TIMING >$MASTERLOG 2>&1 >./scripts/test000-rootdse: line 35: 14977 Segmentation fault (core dumped) >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 >./scripts/test000-rootdse: line 35: 14978 Segmentation fault (core dumped) >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 >./scripts/test000-rootdse: line 35: 14979 Segmentation fault (core dumped) >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 >./scripts/test000-rootdse: line 35: 14980 Segmentation fault (core dumped) >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 >./scripts/test000-rootdse: line 35: 14981 Segmentation fault (core dumped) >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 >./scripts/test000-rootdse: line 35: 14982 Segmentation fault (core dumped) >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 >./scripts/test000-rootdse: kill: (14976) - No such pid >>>>>> Test failed >>>>>> ./scripts/test000-rootdse failed (exit 139) >make[1]: *** [test-ldbm] ïÛÉÂËÁ 139 >make[1]: ÷ÙÈÏÄ ÉÚ ËÁÔÁÌÏÇ `/home/vserge/test/openldap-2.0.12/tests' >make: *** [test] ïÛÉÂËÁ 2 > > >When I change in configure.in lines >from : >dnl ---------------------------------------------------------------- >dnl PF_INET6 support requires getaddrinfo and INET6_ADDRSTRLEN >dnl PF_LOCAL may use getaddrinfo in available >AC_CHECK_FUNCS( inet_ntop ) > >to : >dnl ---------------------------------------------------------------- >dnl PF_INET6 support requires getaddrinfo and INET6_ADDRSTRLEN >dnl PF_LOCAL may use getaddrinfo in available >AC_CHECK_FUNCS( getaddrinfo inet_ntop ) > >Tests is OK.
On Mon, 03 Sep 2001 10:46:27 -0700 "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote: > 2.0.11 and .12 appears to be as you recommend. That is, > include getaddrinfo in that AC_CHECK_FUNCS call. > > Also retest with the provided configure script. I test with both versions and have a troubles. put when i remove this function it work See the patch > > At 12:37 AM 2001-09-03, vserge@menatepspb.msk.ru wrote: > >Full_Name: Volkov Serge > >Version: 2.0.11; 2.0.12 > >OS: Linux (ALTLinux) > >URL: ftp://ftp.openldap.org/incoming/ > >Submission from: (NULL) (194.186.223.229) > > > > > >Hello. > > > >When I configure with the next options i have core dumped with "make test" > >Sorry for Russian messages output, but system configure with Russian locale/ > >Installation procces is > >#autoheader > >#autoconf > >#env CPPFLAGS="-DLDAP_DEBUG" FFLAGS="-pipe -Wall -O2 -fexpensive-optimizations > >-march=i586 -mcpu=i686" CXXFLAGS="-pipe -Wall -O2 -fexpensive-optimizations > >-march=i586 -mcpu=i686" CFLAGS="-pipe -Wall -O2 -fexpensive-optimizations > >-march=i586 -mcpu=i686" ./configure --prefix=/usr --exec-prefix=/usr > >--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share > >--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib > >--localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man > >--infodir=/usr/share/info --without-included-gettext --enable-passwd > >--enable-shell --enable-wrappers --disable-rlookups --without-kerberos > >--datadir=/usr/share/openldap --libexecdir=/usr/sbin --localstatedir=/var/run > >--enable-shared --enable-static --disable-ipv6 --with-readline --with-threads > >--enable-slapd --enable-crypt --enable-syslog --enable-proctitle --enable-ldbm > >--enable-debug > >#make depend > >#make > >#make test > > make test > >cd tests; make test > >make[1]: Вход в каталог `/home/vserge/test/openldap-2.0.12/tests' > >ln: `./data': ошибка перезаписи каталога > >make[1]: [test-ldbm] Ошибка 1 (игнорирована) > >ln: `./schema': Файл существует > >make[1]: [test-ldbm] Ошибка 1 (игнорирована) > >Initiating LDAP tests for LDBM... > >>>>>> Executing all LDAP tests... > >>>>>> Test Directory: . > >>>>>> Backend: ldbm > >>>>>> Starting test000-rootdse ... > >running defines.sh . ldbm > >Datadir is ./data > >Cleaning up in ./test-db... > >Starting slapd on TCP/IP port 9009... > >Using ldapsearch to retrieve all the entries... > >./scripts/test000-rootdse: line 35: 14976 Segmentation fault (core dumped) > >$SLAPD -f $SCHEMACONF -h $MASTERURI -d $LVL $TIMING >$MASTERLOG 2>&1 > >./scripts/test000-rootdse: line 35: 14977 Segmentation fault (core dumped) > >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 > >./scripts/test000-rootdse: line 35: 14978 Segmentation fault (core dumped) > >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 > >./scripts/test000-rootdse: line 35: 14979 Segmentation fault (core dumped) > >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 > >./scripts/test000-rootdse: line 35: 14980 Segmentation fault (core dumped) > >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 > >./scripts/test000-rootdse: line 35: 14981 Segmentation fault (core dumped) > >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 > >./scripts/test000-rootdse: line 35: 14982 Segmentation fault (core dumped) > >$LDAPSEARCH -b "" -s base -h localhost:$PORT '+' >$SEARCHOUT 2>&1 > >./scripts/test000-rootdse: kill: (14976) - No such pid > >>>>>> Test failed > >>>>>> ./scripts/test000-rootdse failed (exit 139) > >make[1]: *** [test-ldbm] Ошибка 139 > >make[1]: Выход из каталог `/home/vserge/test/openldap-2.0.12/tests' > >make: *** [test] Ошибка 2 > > > > > >When I change in configure.in lines > >from : > >dnl ---------------------------------------------------------------- > >dnl PF_INET6 support requires getaddrinfo and INET6_ADDRSTRLEN > >dnl PF_LOCAL may use getaddrinfo in available > >AC_CHECK_FUNCS( inet_ntop ) > > > >to : > >dnl ---------------------------------------------------------------- > >dnl PF_INET6 support requires getaddrinfo and INET6_ADDRSTRLEN > >dnl PF_LOCAL may use getaddrinfo in available > >AC_CHECK_FUNCS( getaddrinfo inet_ntop ) > > > >Tests is OK. > > -- With best wishes, Volkov Serge Network Administrator/Security Administrator
Okay, you had reversed your description in your original post. As a workaround, instead of modifying configure.in/configure, I suggest using: env ac_cv_func_getaddrinfo=no ./configure Kurt
changed notes
changed notes changed state Open to Release moved from Incoming to Software Bugs
changed notes changed state Release to Closed
Hi, I think I have found one possible reason for some problems with getaddrinfo() under Linux with GBU libc Today (to be honest, it was 3 days ago), I had the same problem. A freshly compiled slapd from openldap 2.0.17 crashed during make test. I played around a bit and extracted a test case from tests/scripts/test000-rootdse: LD_LIBRARY_PATH=..... ../servers/slapd/slapd .... This was the offending command. When I only called ../servers/slapd/slapd .... and used the already installed (older) libraries it magically worked. Three days of work with a debugger and searching through the whole system, I found the reason for this strange behaviour: I have libbind.a and the corresponding header files from bind 8.2.x on my system !!! Unfortunately the definition struct addrinfo from GNU libc collides with the same struct of bind 8.2.x: the fields ai_addr and ai_canonname are swapped. When being compiled, libldap*.so and slapd use the /isr/include/netdb.h hader file form the system library, but since since libldap_r.so is being linked together with libbind.a, it provides the wrong version of getaddrinfo() to slapd. The correct version of the funktion is in libc.so and is not being called, since libldap_r.so is first in the list of dynamic libraries. I filed a bug report to the bind people. It got the ticket number [BIND-BUGS #5027] My workaround was wuite simple. I simply changed the order in which libbind and libresolv are checked for res_query and added a check for __res_query in libresolv So, libbind does not get included in the link list for libldap_r.so, and everything works O.K. This is the patch: --- configure.in@@ -709,6 +709,16 @@ +++ configure.in Fri Oct 19 14:55:11 2001 ol_link_dnssrv=no AC_CHECK_FUNC(res_query,:) if test $ac_cv_func_res_query = no ; then + AC_CHECK_LIB(resolv, res_query) + ac_cv_func_res_query=$ac_cv_lib_resolv_res_query +fi + +if test $ac_cv_func_res_query = no ; then + AC_CHECK_LIB(resolv, __res_query) + ac_cv_func_res_query=$ac_cv_lib_resolv___res_query +fi @@ -718,10 +728,6 @@ ac_cv_func_res_query=$ac_cv_lib_bind___res_query fi -if test $ac_cv_func_res_query = no ; then - AC_CHECK_LIB(resolv, res_query) - ac_cv_func_res_query=$ac_cv_lib_resolv_res_query -fi if test "$ac_cv_func_res_query" = yes ; then AC_DEFINE(HAVE_RES_QUERY,1, + +if test $ac_cv_func_res_query = no ; then AC_CHECK_LIB(bind, res_query) ac_cv_func_res_query=$ac_cv_lib_bind_res_query fi Yours Peter PS: I read on the openldap ITS that one guy suggested writing your own implementation of etaddrinfo(). Please do NOT do it !!! The collisions between GNU libc and bind 8 show the dangers of this approach ! -- Peter Marschall | eMail: peter.marschall@mayn.de Scheffelstraße 15 | peter.marschall@is-energy.de 97072 Würzburg | Tel: 0931/14721 PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35
Was -lbind part of the distro's base install? At 11:34 PM 2001-10-19, peter.marschall@mayn.de wrote: >Hi, > >I think I have found one possible reason for some problems >with getaddrinfo() under Linux with GBU libc > >Today (to be honest, it was 3 days ago), I had the same problem. >A freshly compiled slapd from openldap 2.0.17 crashed >during make test. >I played around a bit and extracted a test case from >tests/scripts/test000-rootdse: > LD_LIBRARY_PATH=..... ../servers/slapd/slapd .... >This was the offending command. When I only called > ../servers/slapd/slapd .... >and used the already installed (older) libraries it magically >worked. > >Three days of work with a debugger and searching through >the whole system, I found the reason for this strange behaviour: >I have libbind.a and the corresponding header files from >bind 8.2.x on my system !!! > >Unfortunately the definition struct addrinfo from GNU libc >collides with the same struct of bind 8.2.x: the fields ai_addr and >ai_canonname are swapped. > >When being compiled, libldap*.so and slapd use the >/isr/include/netdb.h hader file form the system library, but >since since libldap_r.so is being linked together with libbind.a, >it provides the wrong version of getaddrinfo() to slapd. >The correct version of the funktion is in libc.so and is not being >called, since libldap_r.so is first in the list of dynamic libraries. > >I filed a bug report to the bind people. >It got the ticket number [BIND-BUGS #5027] > >My workaround was wuite simple. >I simply changed the order in which libbind and libresolv >are checked for res_query and added a check for __res_query >in libresolv >So, libbind does not get included in the link list for libldap_r.so, >and everything works O.K. > >This is the patch: > >--- configure.in@@ -709,6 +709,16 @@ >+++ configure.in Fri Oct 19 14:55:11 2001 > ol_link_dnssrv=no > AC_CHECK_FUNC(res_query,:) > if test $ac_cv_func_res_query = no ; then >+ AC_CHECK_LIB(resolv, res_query) >+ ac_cv_func_res_query=$ac_cv_lib_resolv_res_query >+fi >+ >+if test $ac_cv_func_res_query = no ; then >+ AC_CHECK_LIB(resolv, __res_query) >+ ac_cv_func_res_query=$ac_cv_lib_resolv___res_query >+fi >@@ -718,10 +728,6 @@ > ac_cv_func_res_query=$ac_cv_lib_bind___res_query > fi > >-if test $ac_cv_func_res_query = no ; then >- AC_CHECK_LIB(resolv, res_query) >- ac_cv_func_res_query=$ac_cv_lib_resolv_res_query >-fi > > if test "$ac_cv_func_res_query" = yes ; then > AC_DEFINE(HAVE_RES_QUERY,1, >+ >+if test $ac_cv_func_res_query = no ; then > AC_CHECK_LIB(bind, res_query) > ac_cv_func_res_query=$ac_cv_lib_bind_res_query > fi > > >Yours >Peter > >PS: I read on the openldap ITS that one guy suggested writing > your own implementation of etaddrinfo(). > Please do NOT do it !!! > The collisions between GNU libc and bind 8 show the dangers > of this approach ! > > >-- >Peter Marschall | eMail: peter.marschall@mayn.de >Scheffelstraße 15 | peter.marschall@is-energy.de >97072 Würzburg | Tel: 0931/14721 >PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35
Hi , I'm not sue if I uderstand your question in full. If you ask, if the RPM package, thant contained the libbind.a, has been shipped with the distro, the answer is YES If you ask, it it get's installed in a default installation, the answer is MAYBE. The reason is simple: SuSE offers a lot of options which packages you want to install I think (in other words: I am sure) the problem is not SuSE: the problem is the difference for struct addrinfo between the GNU and bind header files. Even the sources differ (I checked the bind 8.2x seriesfrom www.isc.org and I do not believe SuSE changed all the references to struct addrinfo in GNU libc) Since libbind does not rely on system header files during the compilation and simply uses it's own, it gets the wrong info and is therefore useless with all functions that use struct getaddrinfo. With bind 9.x, bind seems to check for the existence of a struct addrinfo in the system and uses that for the compilation of libbind.a (I did a short check on the sources; no warranty ;-)) Yours Peter On Tuesday 23 October 2001 17:38, you wrote: > Was -lbind part of the distro's base install? > > At 11:34 PM 2001-10-19, peter.marschall@mayn.de wrote: > >Hi, > > > >I think I have found one possible reason for some problems > >with getaddrinfo() under Linux with GBU libc > > > >Today (to be honest, it was 3 days ago), I had the same problem. > >A freshly compiled slapd from openldap 2.0.17 crashed > >during make test. > >I played around a bit and extracted a test case from > >tests/scripts/test000-rootdse: > > LD_LIBRARY_PATH=..... ../servers/slapd/slapd .... > >This was the offending command. When I only called > > ../servers/slapd/slapd .... > >and used the already installed (older) libraries it magically > >worked. > > > >Three days of work with a debugger and searching through > >the whole system, I found the reason for this strange behaviour: > >I have libbind.a and the corresponding header files from > >bind 8.2.x on my system !!! > > > >Unfortunately the definition struct addrinfo from GNU libc > >collides with the same struct of bind 8.2.x: the fields ai_addr and > >ai_canonname are swapped. > > > >When being compiled, libldap*.so and slapd use the > >/isr/include/netdb.h hader file form the system library, but > >since since libldap_r.so is being linked together with libbind.a, > >it provides the wrong version of getaddrinfo() to slapd. > >The correct version of the funktion is in libc.so and is not being > >called, since libldap_r.so is first in the list of dynamic libraries. > > > >I filed a bug report to the bind people. > >It got the ticket number [BIND-BUGS #5027] > > > >My workaround was wuite simple. > >I simply changed the order in which libbind and libresolv > >are checked for res_query and added a check for __res_query > >in libresolv > >So, libbind does not get included in the link list for libldap_r.so, > >and everything works O.K. > > > >This is the patch: > > > >--- configure.in@@ -709,6 +709,16 @@ > >+++ configure.in Fri Oct 19 14:55:11 2001 > > ol_link_dnssrv=no > > AC_CHECK_FUNC(res_query,:) > > if test $ac_cv_func_res_query = no ; then > >+ AC_CHECK_LIB(resolv, res_query) > >+ ac_cv_func_res_query=$ac_cv_lib_resolv_res_query > >+fi > >+ > >+if test $ac_cv_func_res_query = no ; then > >+ AC_CHECK_LIB(resolv, __res_query) > >+ ac_cv_func_res_query=$ac_cv_lib_resolv___res_query > >+fi > >@@ -718,10 +728,6 @@ > > ac_cv_func_res_query=$ac_cv_lib_bind___res_query > > fi > > > >-if test $ac_cv_func_res_query = no ; then > >- AC_CHECK_LIB(resolv, res_query) > >- ac_cv_func_res_query=$ac_cv_lib_resolv_res_query > >-fi > > > > if test "$ac_cv_func_res_query" = yes ; then > > AC_DEFINE(HAVE_RES_QUERY,1, > >+ > >+if test $ac_cv_func_res_query = no ; then > > AC_CHECK_LIB(bind, res_query) > > ac_cv_func_res_query=$ac_cv_lib_bind_res_query > > fi > > > > > >Yours > >Peter > > > >PS: I read on the openldap ITS that one guy suggested writing > > your own implementation of etaddrinfo(). > > Please do NOT do it !!! > > The collisions between GNU libc and bind 8 show the dangers > > of this approach ! > > > > > >-- > >Peter Marschall | eMail: peter.marschall@mayn.de > >Scheffelstraße 15 | peter.marschall@is-energy.de > >97072 Würzburg | Tel: 0931/14721 > >PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35 -- Peter Marschall | eMail: peter.marschall@mayn.de Scheffelstraße 15 | peter.marschall@is-energy.de 97072 Würzburg | Tel: 0931/14721 PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35
At 08:46 AM 2001-10-24, Peter Marschall wrote: >I'm not sue if I uderstand your question in full. The question was aimed at determining whether or not the configure script worked on a default install. I wanted to know if the default install included -lresolv AND -lbind. On most default installs, res_query() is in <resolv.h> and -lresolv (or -lc). Optionally, some folks have it in <resolv.h> and -lbind. In this case, the version in -lresolv needs to be ignored as if the user has optionally installed -lbind, it's assumed that's what the user would like configure to use. Now, if the user updates -lresolv and overwrites (or overrides) resolv.h without removing (or overriding) -lbind, then the user has created an inconsistent environment. It is not reasonable to expect configure to detect (or properly work in) inconsistent environments. configure scripts are designed such that the user can intervene to work through many inconsistencies (namely through environment variables, e.g. ac_cv_*).
At 11:15 AM 2001-10-24, Peter Marschall wrote: >Unfortunately I also want to use getaddrinfo() ;-))) >And I can use it, if I change the order of detection of the >__res_query function. Or modify your environment such that tests which find inconsistent versions are forced to false. env ac_cv_lib_bind_res_query=no ac_cv_lib_bind___res_query=no \ ./configure >BTW in glibc 2.2.2 libresolv contains only __res_query(). >res_query is only an alias in <resolv.h> >Shall I file a bug report about this ? Our latest configure scripts look for both res_query() and __res_query(). >And another one: >The getaddrinfo(3) man page of Linux states: > If node is NULL, the network address in each socket structure is > initialized according to the AI_PASSIVE flag, which is set in the ai_flags > member of the hints parameter. The network address in each socket structure > will be left unspecified if AI_PASSIVE flag is set. This is used by server > applications, which intend to accept client connections on any network > address. The network address will be set to the loopback interface address > if the AI_PASSIVE flag is not set. This is used by client applications, > which intend to connect to a server running on the same network host. >So ai_addr == NULL is legal when (host == NULL) && (ai_flags & AI_PASSIVE). >This might be the case in servers/slapd/daemon.c where it is considered an >error. >Shall I file a bug report / submit a patch for it ? You might check HEAD/OPENLDAP_REL_ENG_2 to see if the problem has already been fixed and, if not, report a bug. Patches provided with bug reports are welcomed.
moved from Software Bugs to Archive.Software Bugs
back trace? reworked in devel and re20