Full_Name: ftp://ftp.openldap.org/incoming/ Version: HEAD OS: SuSE Linux 9.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.23.218) $ ./run -b bdb test000 Cleaning up test run directory leftover from previous run. Running ./scripts/test000-rootdse... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: line 63: kill: (3614) - No such process ldap_bind: Can't contact LDAP server (-1) >>>>> Test failed --------------------------- testrun/slapd.1.log ------------------------------- [..] slapd startup: initiated. backend_startup_one: starting "cn=config" backend_startup_one: starting "o=OpenLDAP Project,l=Internet" bdb_db_open: o=OpenLDAP Project,l=Internet bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: (2) Expect poor performance for suffix o=OpenLDAP Project,l=Internet. bdb_db_open: dbenv_open(./testrun/db.1.a) bdb(o=OpenLDAP Project,l=Internet): Berkeley DB library configured to support only private environments bdb(o=OpenLDAP Project,l=Internet): Berkeley DB library configured to support only private environments bdb_db_open: dbenv_open failed: Invalid argument (22) backend_startup_one: bi_db_open failed! (22) slapd shutdown: initiated slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.
I don't see this on my SuSE 9.2 box, but I'm using a self-compiled libdb. It appears whatever libdb you linked with is missing some requisite features. michael@stroeder.com wrote: > Full_Name: ftp://ftp.openldap.org/incoming/ > Version: HEAD > OS: SuSE Linux 9.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.23.218) > > > $ ./run -b bdb test000 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test000-rootdse... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: line 63: kill: (3614) - No such process > ldap_bind: Can't contact LDAP server (-1) > >>>>>> Test failed >>>>>> > --------------------------- testrun/slapd.1.log ------------------------------- > [..] > slapd startup: initiated. > backend_startup_one: starting "cn=config" > backend_startup_one: starting "o=OpenLDAP Project,l=Internet" > bdb_db_open: o=OpenLDAP Project,l=Internet > bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: > (2) > Expect poor performance for suffix o=OpenLDAP Project,l=Internet. > bdb_db_open: dbenv_open(./testrun/db.1.a) > bdb(o=OpenLDAP Project,l=Internet): Berkeley DB library configured to support > only private environments > bdb(o=OpenLDAP Project,l=Internet): Berkeley DB library configured to support > only private environments > bdb_db_open: dbenv_open failed: Invalid argument (22) > backend_startup_one: bi_db_open failed! (22) > slapd shutdown: initiated > slapd destroy: freeing system resources. > slapd stopped. > connections_destroy: nothing to destroy. > > > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
Howard Chu wrote: > I don't see this on my SuSE 9.2 box, but I'm using a self-compiled > libdb. It appears whatever libdb you linked with is missing some > requisite features. I'm using the standard SuSE 9.3 RPM called db-4.3.27-3. It used to work with it until today. Ciao, Michael.
Michael Ströder wrote: > Howard Chu wrote: > >>I don't see this on my SuSE 9.2 box, but I'm using a self-compiled >>libdb. It appears whatever libdb you linked with is missing some >>requisite features. > > I'm using the standard SuSE 9.3 RPM called db-4.3.27-3. It used to work > with it until today. Please also note that OPENLDAP_REL_ENG_2_3 (synced now) still builds and works as expected. Ciao, Michael.
Michael Ströder wrote: > Michael Ströder wrote: > >> Howard Chu wrote: >> >> >>> I don't see this on my SuSE 9.2 box, but I'm using a self-compiled >>> libdb. It appears whatever libdb you linked with is missing some >>> requisite features. >>> >> I'm using the standard SuSE 9.3 RPM called db-4.3.27-3. It used to work >> with it until today. >> > > Please also note that OPENLDAP_REL_ENG_2_3 (synced now) still builds and > works as expected. > Perhaps this is a result of the OPENLDAP_AC integration into HEAD. Can you send the config.log output for the BDB detection tests from both HEAD and RE23? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
Michael Ströder wrote: > Howard Chu wrote: > >> Well, it clearly shows /usr/lib/libdb-4.3.a getting linked here. Did >> SuSE include a libtool libdb*.la file in /usr/lib? >> > > Yes. > > # rpm -qf /usr/lib/libdb-4.3.a > db-devel-4.3.27-3 > > Ciao, Michael. OK, but is there a libdb-4.3.la file there? I recall we've discussed this issue before on one or the other mailing list; libtool should only be statically linking libraries from the local build tree, not system-installed libraries. I don't remember if there was another libtool option to control this. A workaround would be to (re)move the static library and .la file so they cannot be found at link time. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
Howard Chu wrote: > Michael Ströder wrote: > >> Howard Chu wrote: >> >>> Well, it clearly shows /usr/lib/libdb-4.3.a getting linked here. Did >>> SuSE include a libtool libdb*.la file in /usr/lib? >> >> Yes. >> >> # rpm -qf /usr/lib/libdb-4.3.a >> db-devel-4.3.27-3 > > OK, but is there a libdb-4.3.la file there? Yes, see attachment (re-sent to ITS). Ciao, Michael.
Michael Ströder wrote: > Howard Chu wrote: > >> which is why I only use my own build of BDB in /usr/local. I >> suggest removing the BDB devel rpm from your system... >> > > db-devel also contains the BDB include files (see below). I can see that > compiling by own BDB would help working around this particular problem. > But this is no real solution. Is the solution fixing libtool? > Probably; it should not be selecting the static library here. Notice - you have a /usr/lib/tls/libdb.a as well. The /usr/lib/tls directory is for the NPTL-compatible version. Oddly enough, while NPTL is the default thread library on SuSE 9, the stuff in /usr/lib only supports LinuxThreads. The dynamic linker ld.so is smart enough to find the correct shared libraries at runtime, but libtool doesn't know that it needs to look in lib/tls when linking static libraries. So I guess we need to look into why libtool is using the static version of an installed libtool library. > Ciao, Michael. > > /usr/include/db.h > /usr/include/db4 > /usr/include/db4/db.h > /usr/include/db4/db_185.h > /usr/include/db4/db_cxx.h > /usr/include/db_185.h > /usr/include/db_cxx.h > /usr/lib/libdb-4.3.a > /usr/lib/libdb-4.3.la > /usr/lib/libdb.a > /usr/lib/libdb.so > /usr/lib/libdb_cxx-4.3.a > /usr/lib/libdb_cxx-4.3.la > /usr/lib/libdb_cxx.a > /usr/lib/libdb_cxx.so > /usr/lib/tls/libdb-4.3.a > /usr/lib/tls/libdb-4.3.la > /usr/lib/tls/libdb.a > /usr/lib/tls/libdb.so > /usr/lib/tls/libdb_cxx-4.3.a > /usr/lib/tls/libdb_cxx-4.3.la > /usr/lib/tls/libdb_cxx.a > /usr/lib/tls/libdb_cxx.so > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
OK, this is not a bug in libtool, it's a bug in the SuSE libdb devel RPM. Your .la file says the library name is libdb-4.3.so, but your rpm doesn't provide that file. Since libtool cannot find the shared library it was looking for, it is forced to fallback to the static library. You can either symlink the correct names, or put the correct names into the .la file. This ITS will be closed... Michael Ströder wrote: > Yes, see attachment (re-sent to ITS). > > Ciao, Michael. > > ------------------------------------------------------------------------ > > # libdb-4.3.la - a libtool library file > # Generated by ltmain.sh - GNU libtool 1.5.8 (1.1220.2.117 2004/08/04 14:12:05) > # > # Please DO NOT delete this file! > # It is necessary for linking the library. > > # The name that we can dlopen(3). > dlname='libdb-4.3.so' > > # Names of this library. > library_names='libdb-4.3.so libdb-4.3.so libdb-4.3.so' > > # The name of the static archive. > old_library='libdb-4.3.a' > > > /usr/lib/libdb-4.3.a > /usr/lib/libdb-4.3.la > /usr/lib/libdb.a > /usr/lib/libdb.so > /usr/lib/libdb_cxx-4.3.a > /usr/lib/libdb_cxx-4.3.la > /usr/lib/libdb_cxx.a > /usr/lib/libdb_cxx.so -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
changed notes changed state Open to Feedback
Howard Chu wrote: > OK, this is not a bug in libtool, it's a bug in the SuSE libdb devel RPM. I doubt that, see below. :-/ > Your .la file says the library name is libdb-4.3.so, but your rpm > doesn't provide that file. There are two RPMs installed (see file listings below). db-4.3.27-3: Is required by many other packages and contains /usr/lib/libdb-4.3.so and /usr/lib/tls/libdb-4.3.so db-devel-4.3.27-3: Is optional and contains the BDB header files *.h and libdb*.a and libdb*.la. Obviously it's required to compile OpenLDAP from source. Hmm, could compat-2004.11.13-3 be also relevant? It contains the BDB 3 shared libs. > Since libtool cannot find the shared library > it was looking for, it is forced to fallback to the static library. $ ls -al /usr/lib/libdb-4.3.so -rwxr-xr-x 1 root root 948584 Mar 19 18:40 /usr/lib/libdb-4.3.so* > You can either symlink the correct names, or put the correct names > into the .la file. To me everything seems to be in place. I can't imagine what I should fix on my system. Remember that it used to work before updating libtool in HEAD a couple of days ago and it still works with OPENLDAP_REL_ENG_2_3. How do you explain that? > This ITS will be closed... Hmm... Ciao, Michael. # rpm -ql db /usr/lib/libdb-4.3.so /usr/lib/libdb-4.so /usr/lib/libdb_cxx-4.3.so /usr/lib/libdb_cxx-4.so /usr/lib/tls /usr/lib/tls/libdb-4.3.so /usr/lib/tls/libdb-4.so /usr/lib/tls/libdb_cxx-4.3.so /usr/lib/tls/libdb_cxx-4.so [..snipped /usr/share/doc/*..] # rpm -ql db-devel /usr/include/db.h /usr/include/db4 /usr/include/db4/db.h /usr/include/db4/db_185.h /usr/include/db4/db_cxx.h /usr/include/db_185.h /usr/include/db_cxx.h /usr/lib/libdb-4.3.a /usr/lib/libdb-4.3.la /usr/lib/libdb.a /usr/lib/libdb.so /usr/lib/libdb_cxx-4.3.a /usr/lib/libdb_cxx-4.3.la /usr/lib/libdb_cxx.a /usr/lib/libdb_cxx.so /usr/lib/tls/libdb-4.3.a /usr/lib/tls/libdb-4.3.la /usr/lib/tls/libdb.a /usr/lib/tls/libdb.so /usr/lib/tls/libdb_cxx-4.3.a /usr/lib/tls/libdb_cxx-4.3.la /usr/lib/tls/libdb_cxx.a /usr/lib/tls/libdb_cxx.so [..snipped /usr/share/doc/*..] # ls -al /usr/lib/libdb*|grep -v dbus -rwxr-xr-x 1 root root 56836 Mar 19 20:06 /usr/lib/libdb-1.85.so -rwxr-xr-x 1 root root 512704 Feb 17 2002 /usr/lib/libdb-3.1.so -rwxr-xr-x 1 root root 591100 Feb 17 2002 /usr/lib/libdb-3.3.so -rw-r--r-- 1 root root 1261822 Mar 19 18:40 /usr/lib/libdb-4.3.a -rw-r--r-- 1 root root 799 Mar 19 18:34 /usr/lib/libdb-4.3.la -rwxr-xr-x 1 root root 948584 Mar 19 18:40 /usr/lib/libdb-4.3.so lrwxrwxrwx 1 root root 12 Apr 21 23:28 /usr/lib/libdb-4.so -> libdb-4.3.so -rw-r--r-- 1 root root 1261822 Mar 19 18:40 /usr/lib/libdb.a lrwxrwxrwx 1 root root 12 Apr 21 23:30 /usr/lib/libdb.so -> libdb-4.3.so lrwxrwxrwx 1 root root 13 Apr 21 23:30 /usr/lib/libdb.so.2 -> libdb-1.85.so -rwxr-xr-x 1 root root 264708 Mar 19 20:07 /usr/lib/libdb.so.3 -rw-r--r-- 1 root root 1398530 Mar 19 18:40 /usr/lib/libdb_cxx-4.3.a -rw-r--r-- 1 root root 860 Mar 19 18:35 /usr/lib/libdb_cxx-4.3.la -rwxr-xr-x 1 root root 1046468 Mar 19 18:40 /usr/lib/libdb_cxx-4.3.so lrwxrwxrwx 1 root root 16 Apr 21 23:28 /usr/lib/libdb_cxx-4.so -> libdb_cxx-4.3.so -rw-r--r-- 1 root root 1398530 Mar 19 18:40 /usr/lib/libdb_cxx.a lrwxrwxrwx 1 root root 16 Apr 21 23:30 /usr/lib/libdb_cxx.so -> libdb_cxx-4.3.so
Michael Ströder wrote: > Hmm, could compat-2004.11.13-3 be also relevant? It contains the BDB 3 > shared libs. > No, I don't see anything in the traces showing the old libs being used. > To me everything seems to be in place. I can't imagine what I should fix > on my system. Remember that it used to work before updating libtool in > HEAD a couple of days ago and it still works with OPENLDAP_REL_ENG_2_3. > How do you explain that? > OK, I misread part of the link output, it does find the shared library; it just ignores it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
The attached patch appears to fix the problem with libtool-1.5.18 mistreating installed libtool libraries. The documentation indicates that linking a program with "-static" should only statically link un-installed libtool libraries, but libtool was ignoring their installed status and always statically linking them. This patch tweaks prefer_static_libs to distinguish between the -static and -all-static cases so that the link step can actually perform as documented. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
Howard Chu wrote: > The attached patch appears to fix the problem with libtool-1.5.18 The patch works for me. Ciao, Michael.
changed notes moved from Incoming to Build
changed notes
changed state Feedback to Test
changed notes changed state Test to Closed
Hi Howard, others, Sorry for the long response delay. * Howard Chu wrote on Mon, Aug 29, 2005 at 07:54:27AM CEST: > The attached patch appears to fix the problem with libtool-1.5.18 > mistreating installed libtool libraries. The documentation indicates > that linking a program with "-static" should only statically link > un-installed libtool libraries, but libtool was ignoring their installed > status and always statically linking them. This patch tweaks > prefer_static_libs to distinguish between the -static and -all-static > cases so that the link step can actually perform as documented. I have tested this patch a bit, and forward-ported it to CVS HEAD, see below. In another related mail you wrote: | Something I didn't test properly yet is what happens if the executable | needs to be relinked at install time. Since the just-built libraries | will most likely be installed before the exe is relinked, it seems to me | it may foul up. (But my SuSE system didn't need relinking; will have | to try again on a different platform to see.) Erm, AFAICS the use of `-static' would exactly mean that relinking would not be necessary. Right? I'll wait a couple of days more and test on AIX before comitting. Cheers, Ralf 2005-09-xx Howard Chu <hyc@highlandsun.com> * libltdl/config/ltmain.m4sh (func_mode_link): With `-static', only link statically against uninstalled libtool libraries. Fixes 1.5.x regression to match documented behavior. * NEWS: Updated. Index: NEWS =================================================================== RCS file: /cvsroot/libtool/libtool/NEWS,v retrieving revision 1.183 diff -u -r1.183 NEWS --- NEWS 23 Aug 2005 01:49:36 -0000 1.183 +++ NEWS 25 Sep 2005 11:10:52 -0000 @@ -13,6 +13,8 @@ * Detection of compiler wrappers like distcc/ccache and $host_alias prefix. * Initial Support for FC (modern Fortran). * Fixed a regression that prevented use of libltdl without autotools. +* Fixed a branch-1-5/HEAD regression to only link uninstalled libraries + statically with `-static'. New in 1.9h: 2004-??-??; CVS version 1.9g, Libtool team: * Bug fixes. Index: libltdl/config/ltmain.m4sh =================================================================== RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.11 diff -u -r1.11 ltmain.m4sh --- libltdl/config/ltmain.m4sh 25 Sep 2005 07:35:58 -0000 1.11 +++ libltdl/config/ltmain.m4sh 25 Sep 2005 11:07:42 -0000 @@ -2218,14 +2218,15 @@ compile_command="$compile_command $link_static_flag" finalize_command="$finalize_command $link_static_flag" fi + prefer_static_libs=yes else if test -z "$pic_flag" && test -n "$link_static_flag"; then dlopen_self=$dlopen_self_static fi + prefer_static_libs=built fi build_libtool_libs=no build_old_libs=yes - prefer_static_libs=yes break ;; esac @@ -3598,8 +3599,12 @@ fi link_static=no # Whether the deplib will be linked statically + use_static_libs=$prefer_static_libs + if test "$use_static_libs" = built && test "$installed" = yes; then + use_static_libs=no + fi if test -n "$library_names" && - { test "$prefer_static_libs" = no || test -z "$old_library"; }; then + { test "$use_static_libs" = no || test -z "$old_library"; }; then case $host in *cygwin* | *mingw*) # No point in relinking DLLs because paths are not encoded
Hello again, * Ralf Wildenhues wrote on Sun, Sep 25, 2005 at 01:14:57PM CEST: > > Sorry for the long response delay. If I may repeat that.. :-/ Applied to CVS HEAD and branch-1-5, respectively. Cheers, and sorry again, Ralf 2005-10-29 Howard Chu <hyc@highlandsun.com> * libltdl/config/ltmain.m4sh (func_mode_link): With `-static', only link statically against uninstalled libtool libraries. Fixes 1.5.x regression to match documented behavior. * NEWS: Updated.
moved from Build to Archive.Build
bug in libtool, fixed in HEAD (HEAD Only)