Michael Ströder wrote: Not any more. It used to, when we were using a much older version of libtool. The current version of libtool that we use sets LD_LIBRARY_PATH in the wrapper script that it generates for each dynamically linked binary that it produces, so that line in defines.sh is obsolete. Are you using a different version of libtool? I've got several versions of OpenLDAP installed on my build machines, and have never encountered this problem. The libtool script always explicitly sets the path to the libraries that it linked with. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

Michael Ströder wrote: If you didn't do anything special then the build will use the libtool scripts bundled in the source tree. My mistake, the libtool wrapper script doesn't use LD_LIBRARY_PATH, it actually relinks the binary. mandolin:~/OD/o24/servers/slapd> ls -l slapd .libs -rwxr-xr-x 1 hyc users 6744 2009-03-19 11:33 slapd .libs: total 10907 -rwxr-xr-x 1 hyc users 11156135 2009-03-19 11:33 slapd mandolin:~/OD/o24/servers/slapd> ./slapd -V @(#) $OpenLDAP: slapd 2.4.X (Mar 19 2009 11:33:40) $ hyc@mandolin:/home/hyc/OD/o24/servers/slapd mandolin:~/OD/o24/servers/slapd> ls -l slapd .libs -rwxr-xr-x 1 hyc users 6744 2009-03-19 11:33 slapd .libs: total 21813 -rwxr-xr-x 1 hyc users 11156135 2009-03-19 11:35 lt-slapd -rwxr-xr-x 1 hyc users 11156135 2009-03-19 11:33 slapd mandolin:~/OD/o24/servers/slapd> ldd .libs/lt-slapd linux-vdso.so.1 => (0x00007fff4f5ff000) libldap_r-2.4-releng.so.2 => /home/hyc/OD/o24/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2 (0x00007f8b47122000) liblber-2.4-releng.so.2 => /home/hyc/OD/o24/libraries/liblber/.libs/liblber-2.4-releng.so.2 (0x00007f8b46f13000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f8b46cfa000) libdb-4.7.so => /usr/local/lib/libdb-4.7.so (0x00007f8b469ab000) libmysqlclient_r.so.16 => /usr/local/lib/mysql/libmysqlclient_r.so.16 (0x00007f8b46715000) libndbclient.so.4 => /usr/local/lib/mysql/libndbclient.so.4 (0x00007f8b46347000) librt.so.1 => /lib64/librt.so.1 (0x00007f8b4613e000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f8b45f27000) libstdc++.so.6 => /usr/local/lib/../lib64/libstdc++.so.6 (0x00007f8b45d26000) libc.so.6 => /lib64/libc.so.6 (0x00007f8b459e4000) libgcc_s.so.1 => /usr/local/lib/../lib64/libgcc_s.so.1 (0x00007f8b47438000) libperl.so => /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so (0x00007f8b45691000) libm.so.6 => /lib64/libm.so.6 (0x00007f8b4543b000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8b45202000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8b44fe7000) libgssapi.so.2 => /usr/lib64/libgssapi.so.2 (0x00007f8b44dde000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8b44bda000) libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x00007f8b44993000) libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x00007f8b44624000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8b4440f000) /lib64/ld-linux-x86-64.so.2 (0x00007f8b4736f000) libz.so.1 => /lib64/libz.so.1 (0x00007f8b441fa000) mandolin:~/OD/o24/servers/slapd> ldd .libs/slapd linux-vdso.so.1 => (0x00007fffc23fe000) libldap_r-2.4-releng.so.2 => not found liblber-2.4-releng.so.2 => not found libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f14b9ea6000) libdb-4.7.so => /usr/local/lib/libdb-4.7.so (0x00007f14b9b57000) libmysqlclient_r.so.16 => /usr/local/lib/mysql/libmysqlclient_r.so.16 (0x00007f14b98c1000) libndbclient.so.4 => /usr/local/lib/mysql/libndbclient.so.4 (0x00007f14b94f3000) librt.so.1 => /lib64/librt.so.1 (0x00007f14b92ea000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f14b90d3000) libstdc++.so.6 => /usr/local/lib/../lib64/libstdc++.so.6 (0x00007f14b8ed2000) libc.so.6 => /lib64/libc.so.6 (0x00007f14b8b90000) libgcc_s.so.1 => /usr/local/lib/../lib64/libgcc_s.so.1 (0x00007f14ba188000) libperl.so => /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so (0x00007f14b883d000) libm.so.6 => /lib64/libm.so.6 (0x00007f14b85e7000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f14b83ae000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f14b8193000) libgssapi.so.2 => /usr/lib64/libgssapi.so.2 (0x00007f14b7f8a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f14b7d86000) libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x00007f14b7b3f000) libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x00007f14b77d0000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f14b75bb000) /lib64/ld-linux-x86-64.so.2 (0x00007f14ba0bf000) libz.so.1 => /lib64/libz.so.1 (0x00007f14b73a6000) mandolin:~/OD/o24/servers/slapd> The slapd binary is what gets installed by "make install" (and it probably gets relinked for installation as well). The lt-slapd binary is invoked by the wrapper script when you're running from the build tree, and that's what "make test" will be using. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

Michael Ströder wrote: Only if you already have a fairly broken build environment. Notice that the installed binaries have a different soname from the build binaries: % ls /usr/lib/libl{dap,ber}* /usr/lib/liblber-2.4.so.2 /usr/lib/libldap_r-2.4.so.2 /usr/lib/liblber-2.4.so.2.1.0 /usr/lib/libldap_r-2.4.so.2.1.0 /usr/lib/liblber.a /usr/lib/libldap_r.a /usr/lib/liblber.so /usr/lib/libldap_r.so /usr/lib/libldap-2.4.so.2 /usr/lib/libldap.so /usr/lib/libldap.a % find . -name '*.so.*' ./libldap_r/.libs/libldap_r-2.4-releng.so.2 ./libldap_r/.libs/libldap_r-2.4-releng.so.2.4.1 ./liblber/.libs/liblber-2.4-releng.so.2.4.1 ./liblber/.libs/liblber-2.4-releng.so.2 ./libldap/.libs/libldap-2.4-releng.so.2 ./libldap/.libs/libldap-2.4-releng.so.2.4.1 There's no way it should ever be using your installed libraries when all of the built binaries are using the "-releng" tag in their soname. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

--On Friday, March 20, 2009 2:01 AM +0100 Michael Ströder <michael(a)stroeder.com&gt; wrote: I regularly build OpenLDAP on 16 different boxes, covering 11 different OSes, 2 of which are OSX (10.4 and 10.5). I have never encountered this issue, even though all of those 16 boxes have the ldap libraries installed in /usr/lib. My files end up being linked correctly. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

--On Friday, March 20, 2009 2:15 AM +0100 Michael Ströder <michael(a)stroeder.com&gt; wrote: I don't know, but here's my example configure: LDFLAGS="-L/usr/local/lib -R/usr/local/lib" LD_LIBRARY_PATH=/usr/local/lib CPPFLAGS="-I/usr/local/include" CC=gcc CXX=g++ CFLAGS='-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER' CXXFLAGS='-g -O2' sh ../configure --datadir='${prefix}/lib' --libexecdir='${prefix}/lib' --sharedstatedir='${prefix}/lib' --prefix=/usr/local --disable-ipv6 --with-cyrus-sasl --with-tls --enable-dynamic --enable-slapd --enable-modules --enable-spasswd --enable-rewrite --enable-rlookups --enable-wrappers --enable-backends=mod --disable-shell --disable-sql --enable-overlays=mod --enable-debug --enable-slapi=yes --disable-ndb and here's my resulting slapd: [root@freelancer .libs]# ldd slapd libldap_r-2.4.so.2 => not found liblber-2.4.so.2 => not found libuuid.so.1 => /lib64/libuuid.so.1 (0x000000395ec00000) libdb-4.7.so => /usr/local/lib/libdb-4.7.so (0x00002b3129678000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b31299c1000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x00002b3129bdb000) libgssapi.so.2 => /usr/local/lib/libgssapi.so.2 (0x00002b3129df3000) libheimntlm.so.0 => /usr/local/lib/libheimntlm.so.0 (0x00002b312a022000) libkrb5.so.25 => /usr/local/lib/libkrb5.so.25 (0x00002b312a227000) libhx509.so.4 => /usr/local/lib/libhx509.so.4 (0x00002b312a4f4000) libwind.so.0 => /usr/local/lib/libwind.so.0 (0x00002b312a738000) libasn1.so.8 => /usr/local/lib/libasn1.so.8 (0x00002b312a95f000) libcom_err.so.1 => /usr/local/lib/libcom_err.so.1 (0x00002b312abe4000) libroken.so.18 => /usr/local/lib/libroken.so.18 (0x00002b312ade7000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003960400000) libssl.so.0.9.8 => /usr/local/lib/libssl.so.0.9.8 (0x00002b312affb000) libcrypto.so.0.9.8 => /usr/local/lib/libcrypto.so.0.9.8 (0x00002b312b247000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003961c00000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x00002b312b5c4000) libdl.so.2 => /lib64/libdl.so.2 (0x000000395e400000) libwrap.so.0 => /usr/lib64/libwrap.so.0 (0x00002b312b7cc000) libc.so.6 => /lib64/libc.so.6 (0x000000395e000000) /lib64/ld-linux-x86-64.so.2 (0x000000395dc00000) libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003961400000) And here is my resulting lt-slapd: [root@freelancer .libs]# ldd lt-slapd libldap_r-2.4.so.2 => /usr/local/build/openldap-2.4.16/qbuild/libraries/libldap_r/.libs/libldap_r-2.4.so.2 (0x00002b99e1623000) liblber-2.4.so.2 => /usr/local/build/openldap-2.4.16/qbuild/libraries/liblber/.libs/liblber-2.4.so.2 (0x00002b99e186e000) libuuid.so.1 => /lib64/libuuid.so.1 (0x000000395ec00000) libdb-4.7.so => /usr/local/lib/libdb-4.7.so (0x00002b99e1a89000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b99e1dd2000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x00002b99e1fec000) libgssapi.so.2 => /usr/local/lib/libgssapi.so.2 (0x00002b99e2204000) libheimntlm.so.0 => /usr/local/lib/libheimntlm.so.0 (0x00002b99e2433000) libkrb5.so.25 => /usr/local/lib/libkrb5.so.25 (0x00002b99e2638000) libhx509.so.4 => /usr/local/lib/libhx509.so.4 (0x00002b99e2905000) libwind.so.0 => /usr/local/lib/libwind.so.0 (0x00002b99e2b49000) libasn1.so.8 => /usr/local/lib/libasn1.so.8 (0x00002b99e2d70000) libcom_err.so.1 => /usr/local/lib/libcom_err.so.1 (0x00002b99e2ff5000) libroken.so.18 => /usr/local/lib/libroken.so.18 (0x00002b99e31f8000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003960400000) libssl.so.0.9.8 => /usr/local/lib/libssl.so.0.9.8 (0x00002b99e340c000) libcrypto.so.0.9.8 => /usr/local/lib/libcrypto.so.0.9.8 (0x00002b99e3658000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003961c00000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x00002b99e39d5000) libdl.so.2 => /lib64/libdl.so.2 (0x000000395e400000) libwrap.so.0 => /usr/lib64/libwrap.so.0 (0x00002b99e3bdd000) libc.so.6 => /lib64/libc.so.6 (0x000000395e000000) /lib64/ld-linux-x86-64.so.2 (0x000000395dc00000) libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003961400000) and I have no installed openldap in /usr/local/* The /usr/lib dir has pre-existing libldap: [root@freelancer lib]# ls -l libldap* lrwxrwxrwx 1 root root 21 Jan 14 09:48 libldap-2.3.so.0 -> libldap-2.3.so.0.2.15 -rwxr-xr-x 1 root root 238544 Jul 9 2008 libldap-2.3.so.0.2.15 lrwxrwxrwx 1 root root 23 Jan 14 09:48 libldap_r-2.3.so.0 -> libldap_r-2.3.so.0.2.15 -rwxr-xr-x 1 root root 255636 Jul 9 2008 libldap_r-2.3.so.0.2.15 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

Michael Ströder writes: Does that help? man ld.so on RHEL 5.3 says $LD_LIBRARY_PATH is used _after_ an Elf binary's DT_RPATH attribute, unless the DT_RUNPATH attribute is also set. ld does not set DT_RUNPATH by default. So when I edit servers/slapd/slapd and put echo "LD_LIBRARY_PATH=$LD_LIBRARY_PATH" >&2 ldd "$progdir/$program" >&2 before exec "$progdir/$program" ${1+"$@"} it still shows that the installed libraries are used. It works if I include "-Wl,--enable-new-dtags" in ./configure LDFLAGS. This sets the DT_RUNPATH attribute, and I don't know what else. The ld(1) manpage says --enable-new-dtags --disable-new-dtags This linker can create the new dynamic tags in ELF. But the older ELF systems may not understand them. If you specify --enable-new-dtags, the dynamic tags will be created as needed. If you specify --disable-new-dtags, no new dynamic tags will be created. By default, the new dynamic tags are not created. Note that those options are only available for ELF systems. Only append the ":" if LD_LIBRARY_PATH is already set, otherwise I suppose you in practice include "." the path. Also, include slapi: LD_LIBRARY_PATH=$TESTWD/../libraries/liblber/.libs:$TESTWD/../libraries/libldap/.libs:$TESTWD/../libraries/libldap_r/.libs:$TESTWD/../servers/slapd/slapi/.libs${LD_LIBRARY_PATH+':'}${LD_LIBRARY_PATH} export LD_LIBRARY_PATH -- Hallvard

Michael Ströder wrote: According to a message received off-list this seems to be misunderstanding: I've just let "make test" run until test002 to check whether the LD_LIBRARY_PATH line suggested by Hallvard works since it would fail right in test000 if the pre-installed libs are used from /usr/lib instead of the libs in the build tree. Ciao, Michael.

Howard Chu wrote: Well, it works in my setup. Maybe I will add it to my build script before make test. Ok. Ok, now I can see the problem. My build script (see below, lines wrapped) has vars set for the case when BDB or SASL are installed in different prefixes. At the moment I'm building against the pre-installed ones and set these prefixes to /usr. Because of this /usr/lib gets prepended to rpath: [..] 0x0000000f (RPATH) Library rpath: [/usr/lib:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_r/.libs:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/liblber/.libs:/opt/openldap-RE24/lib] 0x0000001d (RUNPATH) Library runpath: [/usr/lib:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_r/.libs:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/liblber/.libs:/opt/openldap-RE24/lib] [..] Any idea how to change the order without having to remove the linker flags completely? It's so convenient just to change a prefix. Ciao, Michael. -------------------------------- snip -------------------------------- OPENLDAP_VERSION=$1 #BDB_PREFIX="/opt/bdb-4.6" BDB_PREFIX="/usr" SSL_PREFIX="/usr" KRB5_PREFIX="/usr" SASL_PREFIX="/usr" OPENLDAP_PREFIX="/opt/openldap-${OPENLDAP_VERSION}" export CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER" export CPPFLAGS="-I${SSL_PREFIX}/include -I${BDB_PREFIX}/include -I${KRB5_PREFIX}/include -I${SASL_PREFIX}/include" #export CPPFLAGS="-I${SSL_PREFIX}/include -I${BDB_PREFIX}/include" export LDFLAGS="-L${BDB_PREFIX}/lib -L${SSL_PREFIX}/lib -L${KRB5_PREFIX}/lib -L${SASL_PREFIX}/lib -Wl,-R${SSL_PREFIX}/lib -Wl,-R${BDB_PREFIX}/lib,-R${SASL_PREFIX}/lib,-R${KRB5_PREFIX}/lib" make distclean ./configure \ --prefix=${OPENLDAP_PREFIX} \ --enable-dynamic=yes \ --enable-ndb=no \ --enable-backends=mod \ --enable-overlays=mod \ --enable-perl=no \ --enable-shell=no \ --enable-local=yes \ --with-cyrus-sasl=yes \ --with-kerberos=yes \ --with-tls=yes \ --with-threads=yes \ --with-odbc=auto \ --enable-crypt=yes \ --enable-spasswd=yes \ --enable-lmpasswd=yes \ --enable-shared=yes make depend make ulimit -c unlimited SLEEP1=7 SLEEP2=15 make test

Quanah Gibson-Mount wrote: Yes, I know. But I just wanted to be flexible when testing different builds of BDB, SASL etc. Setting one prefix is more convenient than editing several lines. Ciao, Michael.

Quanah Gibson-Mount writes: s/even though/because/. At least if this is the problem which bit me: ./configure LDFLAGS="<-L and -Wl,-rpath,><directory with OpenLDAP libs>" -- Hallvard

Michael Ströder writes: The directory also has other libs I need. '-Wl,-rpath,' sets which directories to use at run time, similar to -R on some other systems. -- Hallvard