On Wed, 2003-11-19 at 08:39, Rhugga wrote: > Heya RH Peeps, > > I am getting errant results when defining library paths in > /etc/ld.so.conf, mainly with some ldap stuff I am working on. > > For example here is my ld.so.conf: > /usr/local/openldap-2.1.9/lib > /usr/local/net-snmp-5.0.9/lib > /usr/local/openssl-0.9.7c/lib > /usr/local/php-4.3.4/lib > /usr/local/cyrus-imapd-2.1.15/lib > /usr/kerberos/lib > /usr/X11R6/lib > /usr/lib/qt-3.1/lib > /usr/lib/qt2/lib > /usr/lib/sane > /usr/lib/mysql > > So based on this and the absense of a defined LD_LIBRARY_PATH, the > default would be to use the first library found, thus the ldap lib in > /usr/local/openldap-2.1.9/lib not under /usr/lib, correct? > > This is also verified as follows: > syslog:~ #ldconfig -p | grep ldap | more > libldap_r.so.2 (libc6) => > /usr/local/openldap-2.1.9/lib/libldap_r.so.2 > libldap_r.so.2 (libc6) => /usr/lib/libldap_r.so.2 > libldap_r.so (libc6) => /usr/local/openldap-2.1.9/lib/libldap_r.so > libldap_r.so (libc6) => /usr/lib/libldap_r.so > libldap.so.2 (libc6) => /usr/local/openldap-2.1.9/lib/libldap.so.2 > libldap.so.2 (libc6) => /usr/lib/libldap.so.2 > libldap.so (libc6) => /usr/local/openldap-2.1.9/lib/libldap.so > libldap.so (libc6) => /usr/lib/libldap.so > liblber.so.2 (libc6) => /usr/local/openldap-2.1.9/lib/liblber.so.2 > liblber.so (libc6) => /usr/local/openldap-2.1.9/lib/liblber.so > > However, when I compile so code and link with some ldap libraries, it is > somehow using the copy in /usr/lib even though ldd say this: > > syslog:/usr/bin #ldd ldap_chk > libldap.so.2 => /usr/local/openldap-2.1.9/lib/libldap.so.2 > (0x40033000) > liblber.so.2 => /usr/local/openldap-2.1.9/lib/liblber.so.2 > (0x4005b000) > libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40066000) > libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40071000) > libpam.so.0 => /lib/libpam.so.0 (0x40078000) > libssl.so.4 => /lib/libssl.so.4 (0x40080000) > libcrypto.so.4 => /lib/libcrypto.so.4 (0x400b5000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x401a7000) > libnsl.so.1 => /lib/libnsl.so.1 (0x401d4000) > libresolv.so.2 => /lib/libresolv.so.2 (0x401e9000) > libdl.so.2 => /lib/libdl.so.2 (0x401fb000) > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x401ff000) > libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 > (0x40213000) > libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40226000) > libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40284000) > libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40286000) > libz.so.1 => /usr/lib/libz.so.1 (0x40296000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Very odd, but I verified that it is indeed accessing the libraries in > /usr/lib/libldap.so.2 and not /usr/local/openldap-2.1.9/lib/libldap.so.2 > by renaming /usr/local/openldap-2.1.9 to /usr/local/test-openldap-2.1.9 > > Arg. I need the latest version of openldap, the latest RH rpm will not > work for me. (the code I am writing needs to support solaris and other > Unixes as well so the reason I need the later openldap is for a solaris > problem, but I want to standardize accross all platforms) > > Anyway, just wondering if anyone has seen this problem. > > System Specs: > Red Hat 9.0 with all updates > Kernel 2.4.20-20.9smp (stock) > Dual 1.7 Ghz Xeons, 2GB ECC RAM / Tyan MB > SysKonnect Gigabit NIC > Using the default development tools with the exception of the packages I > installed into /usr/local. (listed above in the ld.so.conf file) > > Thanks for any help, > CC > > -- > Chuck Carson - Sr. Systems Engineer > Syrrx, Inc. > 10410 Science Center Drive > San Diego, CA 92121 > Work: 858.731.3540 > Cell: 858.967.5959 I was using ldconfig recently and did a man on it. I thought I read as I was scanning it that it does not recognize symlinks and ignores them. ldconfig creates the necessary links and cache (for use by the run-time linker, ld.so) to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/usr/lib and /lib). ldconfig checks the header and file names of the libraries it encounters when determining which versions should have their links updated. ldconfig ignores symbolic links when scanning for libraries. Ed -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
