HI!
I'm running make test on a system where older OpenLDAP libs are installed from the Linux distribution packages (here RPMs of openSUSE 11.1). This leads to problems during 'make test':
LDAP vendor version mismatch: library 20413, header 20416
Test failed ./scripts/test000-rootdse failed (exit 1)
make[2]: *** [bdb-yes] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2
$ grep -r LD_LIBRARY_PATH tests/ tests/scripts/defines.sh:LD_LIBRARY_PATH=$TESTWD/../libraries:${LD_LIBRARY_PATH} export LD_LIBRARY_PATH
Hmm...
find libraries/ -name "*.so" libraries/libldap_r/.libs/libldap_r.so libraries/liblber/.libs/liblber.so libraries/libldap/.libs/libldap.so
Does setting LD_LIBRARY_PATH in tests/scripts/defines.sh have any effect?
I've changed this line to (line wrapped)
LD_LIBRARY_PATH=$TESTWD/../libraries/liblber/.libs:$TESTWD/../libraries/libldap/.libs:$TESTWD/../libraries/libldap_r/.libs:${LD_LIBRARY_PATH} export LD_LIBRARY_PATH
and now it works as expected.
This might also be the reason that some tests failed in the past although gdb reported that the right libs were used. But the symbols were missing in gdb's stack trace.
Ciao, Michael.
Michael Ströder wrote:
HI!
I'm running make test on a system where older OpenLDAP libs are installed from the Linux distribution packages (here RPMs of openSUSE 11.1). This leads to problems during 'make test':
LDAP vendor version mismatch: library 20413, header 20416
Test failed ./scripts/test000-rootdse failed (exit 1)
make[2]: *** [bdb-yes] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2
$ grep -r LD_LIBRARY_PATH tests/ tests/scripts/defines.sh:LD_LIBRARY_PATH=$TESTWD/../libraries:${LD_LIBRARY_PATH} export LD_LIBRARY_PATH
Hmm...
find libraries/ -name "*.so" libraries/libldap_r/.libs/libldap_r.so libraries/liblber/.libs/liblber.so libraries/libldap/.libs/libldap.so
Does setting LD_LIBRARY_PATH in tests/scripts/defines.sh have any effect?
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.
I've changed this line to (line wrapped)
LD_LIBRARY_PATH=$TESTWD/../libraries/liblber/.libs:$TESTWD/../libraries/libldap/.libs:$TESTWD/../libraries/libldap_r/.libs:${LD_LIBRARY_PATH} export LD_LIBRARY_PATH
and now it works as expected.
This might also be the reason that some tests failed in the past although gdb reported that the right libs were used. But the symbols were missing in gdb's stack trace.
Ciao, Michael.
Howard Chu wrote:
Michael Ströder wrote:
Does setting LD_LIBRARY_PATH in tests/scripts/defines.sh have any effect?
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.
Hmm...
Are you using a different version of libtool?
How can I find out? I didn't specify anything special. However there is a libtool package installed:
# rpm -qf `which libtool` libtool-2.2.6-1.20
See excerpts of config.log below.
Ciao, Michael.
-------------------------------- snip -------------------------------- [..] configure: In function 'main': configure:11224: warning: incompatible implicit declaration of built-in function 'exit' configure:11231: $? = 0 configure:11249: result: yes configure:11272: checking if libtool supports shared libraries configure:11274: result: yes configure:11277: checking whether to build shared libraries configure:11298: result: yes configure:11301: checking whether to build static libraries configure:11305: result: yes configure:11397: creating libtool configure:12458: checking how to run the C preprocessor configure:12574: result: cc -E configure:12603: cc -E -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL conftest.c configure:12609: $? = 0 configure:12640: cc -E -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL conftest.c conftest.c:26:28: error: ac_nonexistent.h: No such file or directory configure:12646: $? = 1 [..] LIBTOOL='$(SHELL) $(top_builddir)/libtool'
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Does setting LD_LIBRARY_PATH in tests/scripts/defines.sh have any effect?
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.
Hmm...
Are you using a different version of libtool?
How can I find out? I didn't specify anything special. However there is a libtool package installed:
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 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.
And what can I do about it?
Things like this can lead to a bunch of errornous ITS reports.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu 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.
And what can I do about it?
Things like this can lead to a bunch of errornous ITS reports.
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 wrote:
Michael Ströder wrote:
Howard Chu 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.
And what can I do about it?
Things like this can lead to a bunch of errornous ITS reports.
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.
1. When Quanah announces that RE24 is tagged and ready for release "-releng" is already removed.
2. It's my strong opinion that if someone unpacks a release tar.gz and builds it running "make test" should not conflict with an already installed version of /usr/lib/libl{dap,ber}*. It's quite normal that you build and test before installing the next release. Isn't it? Having a separate build system without any pre-installed libldap is nearly impossible today. On openSUSE even the software installation tool zypper has a dependency on libldap.
Ciao, Michael.
--On Friday, March 20, 2009 2:01 AM +0100 Michael Ströder michael@stroeder.com wrote:
- It's my strong opinion that if someone unpacks a release tar.gz and
builds it running "make test" should not conflict with an already installed version of /usr/lib/libl{dap,ber}*. It's quite normal that you build and test before installing the next release. Isn't it? Having a separate build system without any pre-installed libldap is nearly impossible today. On openSUSE even the software installation tool zypper has a dependency on libldap.
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
Quanah Gibson-Mount wrote:
--On Friday, March 20, 2009 2:01 AM +0100 Michael Ströder michael@stroeder.com wrote:
- It's my strong opinion that if someone unpacks a release tar.gz and
builds it running "make test" should not conflict with an already installed version of /usr/lib/libl{dap,ber}*. It's quite normal that you build and test before installing the next release. Isn't it? Having a separate build system without any pre-installed libldap is nearly impossible today. On openSUSE even the software installation tool zypper has a dependency on libldap.
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.
So then please tell me what I'm doing wrong.
Please note that 1. the build itself works correctly. Only running "make test" without prior "make install" is the problem. 2. I'm installing under a separate prefix not /usr/lib.
Ciao, Michael.
--On Friday, March 20, 2009 2:15 AM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Friday, March 20, 2009 2:01 AM +0100 Michael Ströder michael@stroeder.com wrote:
- It's my strong opinion that if someone unpacks a release tar.gz and
builds it running "make test" should not conflict with an already installed version of /usr/lib/libl{dap,ber}*. It's quite normal that you build and test before installing the next release. Isn't it? Having a separate build system without any pre-installed libldap is nearly impossible today. On openSUSE even the software installation tool zypper has a dependency on libldap.
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.
So then please tell me what I'm doing wrong.
Please note that
- the build itself works correctly. Only running "make test" without
prior "make install" is the problem. 2. I'm installing under a separate prefix not /usr/lib.
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
Quanah Gibson-Mount wrote:
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'
In my build script I don't even set LD_LIBRARY_PATH.
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
And that's the difference:
$ ldd servers/slapd/.libs/slapd [..] libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0xb7fc0000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0xb7fb0000) [..]
[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)
Is /usr/local/build/openldap-2.4.16/qbuild your source and build directory?
In my source directory it's different:
$ ldd servers/slapd/.libs/lt-slapd linux-gate.so.1 => (0xffffe000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0xb7f21000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0xb7f11000)
and I have no installed openldap in /usr/local/*
The /usr/lib dir has pre-existing libldap:
So this doesn't get linked because you set LD_LIBRARY_PATH=/usr/local/lib. I don't want that because this might break other things in a local setup where LD_LIBRARY_PATH in a shell profile.
So this works great for you. But this won't work for others. And I'd really like to know what's wrong with my suggestion to generally set LD_LIBRARY_PATH in tests/scripts/defines.sh like this:
LD_LIBRARY_PATH=$TESTWD/../libraries/liblber/.libs:$TESTWD/../libraries/libldap/.libs:$TESTWD/../libraries/libldap_r/.libs:${LD_LI BRARY_PATH} export LD_LIBRARY_PATH
Ciao, Michael.
Michael Ströder writes:
So this works great for you. But this won't work for others. And I'd really like to know what's wrong with my suggestion to generally set LD_LIBRARY_PATH in tests/scripts/defines.sh like this:
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.
LD_LIBRARY_PATH=$TESTWD/../libraries/liblber/.libs:$TESTWD/../libraries/libldap/.libs:$TESTWD/../libraries/libldap_r/.libs:${LD_LI BRARY_PATH} export LD_LIBRARY_PATH
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 B Furuseth wrote:
Michael Ströder writes:
So this works great for you. But this won't work for others. And I'd really like to know what's wrong with my suggestion to generally set LD_LIBRARY_PATH in tests/scripts/defines.sh like this:
Does that help?
Yes, definitely in my case.
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.
Well, you explicitly set the run-time linking option with linker options. I'm not doing this.
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
Seems to work (at least until test002)...
Ciao, Michael.
Michael Ströder wrote:
Hallvard B Furuseth wrote:
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
Seems to work (at least until test002)...
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.
Hallvard B Furuseth wrote:
Michael Ströder writes:
So this works great for you. But this won't work for others. And I'd really like to know what's wrong with my suggestion to generally set LD_LIBRARY_PATH in tests/scripts/defines.sh like this:
Setting LD_LIBRARY_PATH in defines.sh was always lame at best. In particular, it does nothing for systems like HPUX or AIX (which use SHLIB_PATH and LIBPATH, respectively) and I imagine there are many other systems in the same boat. Part of the point in using libtool is to avoid having to muck with this kind of stuff directly in our own scripts.
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.
But libtool does by default - look at the DYNAMIC section of lt-slapd:
mandolin:~/OD/hobj/servers/slapd/.libs> readelf -d lt-slapd
Dynamic section at offset 0x125d80 contains 33 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libldap_r-2-devel.so.0] 0x0000000000000001 (NEEDED) Shared library: [liblber-2-devel.so.0] 0x0000000000000001 (NEEDED) Shared library: [libdb-4.7.so] 0x0000000000000001 (NEEDED) Shared library: [libsasl2.so.2] 0x0000000000000001 (NEEDED) Shared library: [libgssapi.so.2] 0x0000000000000001 (NEEDED) Shared library: [libssl.so.0.9.8] 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.0.9.8] 0x0000000000000001 (NEEDED) Shared library: [libresolv.so.2] 0x0000000000000001 (NEEDED) Shared library: [libltdl.so.3] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000f (RPATH) Library rpath: [/home/hyc/OD/hobj/libraries/libldap_r/.libs:/home/hyc/OD/hobj/libraries/liblber/.libs] 0x000000000000001d (RUNPATH) Library runpath: [/home/hyc/OD/hobj/libraries/libldap_r/.libs:/home/hyc/OD/hobj/libraries/liblber/.libs] 0x000000000000000c (INIT) 0x4159d0 0x000000000000000d (FINI) 0x4c5694 0x0000000000000004 (HASH) 0x4002c8 0x0000000000000005 (STRTAB) 0x40c0b8 0x0000000000000006 (SYMTAB) 0x402bc0 0x000000000000000a (STRSZ) 26669 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x725fe8 0x0000000000000002 (PLTRELSZ) 8856 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x413738 0x0000000000000007 (RELA) 0x4135d0 0x0000000000000008 (RELASZ) 360 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x413550 0x000000006fffffff (VERNEEDNUM) 2 0x000000006ffffff0 (VERSYM) 0x4128e6 0x0000000000000000 (NULL) 0x0
That's on a build with no special linker flags configured.
With all default settings, I've never run into any library mismatch problems. We already know about Hallvard's setup; I don't believe there's anything we can or should do to accommodate nonstandard linker settings. When you change the linker flags, you should know what you're doing.
Howard Chu wrote:
Hallvard B Furuseth wrote:
Michael Ströder writes:
So this works great for you. But this won't work for others. And I'd really like to know what's wrong with my suggestion to generally set LD_LIBRARY_PATH in tests/scripts/defines.sh like this:
Setting LD_LIBRARY_PATH in defines.sh was always lame at best.
Well, it works in my setup. Maybe I will add it to my build script before make test.
In particular, it does nothing for systems like HPUX or AIX (which use SHLIB_PATH and LIBPATH, respectively) and I imagine there are many other systems in the same boat. Part of the point in using libtool is to avoid having to muck with this kind of stuff directly in our own scripts.
Ok.
That's on a build with no special linker flags configured.
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
--On Saturday, March 21, 2009 12:07 AM +0100 Michael Ströder michael@stroeder.com wrote:
Any idea how to change the order without having to remove the linker flags completely? It's so convenient just to change a prefix.
Omit the flag if the prefix is set to /usr
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Saturday, March 21, 2009 12:07 AM +0100 Michael Ströder michael@stroeder.com wrote:
Any idea how to change the order without having to remove the linker flags completely? It's so convenient just to change a prefix.
Omit the flag if the prefix is set to /usr
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.
--On Saturday, March 21, 2009 12:26 AM +0100 Michael Ströder michael@stroeder.com wrote:
Any idea how to change the order without having to remove the linker flags completely? It's so convenient just to change a prefix.
Omit the flag if the prefix is set to /usr
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.
I mean, make your script smarter. Use more variables in an if statement, so that each ends up only being defined if there's something to define.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount writes:
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.
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 B Furuseth wrote:
Quanah Gibson-Mount writes:
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.
s/even though/because/. At least if this is the problem which bit me: ./configure LDFLAGS="<-L and -Wl,-rpath,><directory with OpenLDAP libs>"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What's the reason for doing this?
Ciao, Michael.
Michael Ströder writes:
Hallvard B Furuseth wrote:
Quanah Gibson-Mount writes:
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.
s/even though/because/. At least if this is the problem which bit me: ./configure LDFLAGS="<-L and -Wl,-rpath,><directory with OpenLDAP libs>"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^What's the reason for doing this?
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 B Furuseth -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount