| Summary: | nss_ldap-207-r1 links to wrong libdb! | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bart Lauwers (RETIRED) <blauwers> |
| Component: | [OLD] Core system | Assignee: | Robin Johnson <robbat2> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | ht_gentoo04 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Bart Lauwers (RETIRED)
2003-11-13 06:19:05 UTC
Is it possible to get some feedbac on this? I can look into fixing the ebuild myself if you like. i cannot reproduce this at all with the recent nss_ldap. There should be absolutely no problems with nss_ldap with db4.0 or db4.1 (it works for me!). Well I just re-emerged nss_ldap and it broke:
bash-2.05b# getent passwd > /dev/null
getent: relocation error: /lib/libnss_ldap.so.2: undefined symbol: __db185_open
bash-2.05b# ldd /lib/libnss_ldap.so.2
libldap.so.2 => /usr/lib/libldap.so.2 (0x40030000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x4d0e8000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x444a8000)
libdl.so.2 => /lib/libdl.so.2 (0x4447f000)
libnsl.so.1 => /lib/libnsl.so.1 (0x45369000)
libresolv.so.2 => /lib/libresolv.so.2 (0x44831000)
libc.so.6 => /lib/libc.so.6 (0x44354000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x40058000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x400b6000)
libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0x400c6000)
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x44ba6000)
libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x44888000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
bash-2.05b# qpkg -I -v sys-libs/db
sys-libs/db-1.85-r1 *
sys-libs/db-4.0.14-r2 *
sys-libs/db-3.2.9-r9 *
bash-2.05b# qpkg -I -v nss_ldap
net-libs/nss_ldap-207-r1 *
bash-2.05b#
Anything you want me to try?
After some digging I believe this may be the cause of the issue: bash-2.05b$ ./fileconflict.pl | grep sys-libs/db-3 Conflict: (S)/usr/include/db.h, sys-libs/db-4.0.14-r2 sys-libs/db-3.2.9-r9 sys-libs/db-4.1.25_p1-r3 Conflict: (S)/usr/include/db_185.h, sys-libs/db-4.0.14-r2 sys-libs/db-3.2.9-r9 sys-libs/db-4.1.25_p1-r3 Conflict: (S)/usr/lib/libdb.a, sys-libs/db-4.0.14-r2 sys-libs/db-3.2.9-r9 sys-libs/db-4.1.25_p1-r3 Conflict: (S)/usr/lib/libdb.so, sys-libs/db-4.0.14-r2 sys-libs/db-3.2.9-r9 sys-libs/db-4.1.25_p1-r3 Conflict: (S)/usr/lib/libdb_cxx.a, sys-libs/db-4.0.14-r2 sys-libs/db-3.2.9-r9 sys-libs/db-4.1.25_p1-r3 Conflict: (S)/usr/lib/libdb_cxx.so, sys-libs/db-4.0.14-r2 sys-libs/db-3.2.9-r9 sys-libs/db-4.1.25_p1-r3 bash-2.05b$ However I don't feel brave enough today to re-emerge this makes we wonder if it could be the cause for this working for you, if you received your db-3 update after your db-4 update. I got the problem after emerging nss_ldap (last stable 207-r1): undefined reference to `__db185_open` nss_ldap can't work with ebuild db-4.0.14-r2 or 4.1.25_p1-r3 but works with 3.2.9-r9 (this last one was the frist version present on my Gentoo). I think the last one emerged overide the others around le -ldb flag. I got nss_ldap working with adding -ldb-3 flag in the Makfile on the LIBS line So I have thought that the real problem is ebuikd of db4 /db4.1 (those I have are up to date) which is not configured with '--enable-compat185' (DB 1.85 compatibility API) but I checked the ebuild and it is configured with. Finaly I rebuild nss_ldap and on the configure the output was : checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking db1/db.h usability... yes checking db1/db.h presence... yes checking for db1/db.h... yes checking db_185.h usability... yes checking db_185.h presence... yes checking for db_185.h... yes checking db3/db_185.h usability... yes checking db3/db_185.h presence... yes checking for db3/db_185.h... yes The problem is around there, nss_ldap seems to be improperly built against db3 rather than db4 (no check for db4 / db4.1) but the flag -ldb links to libdb-4.1.so ... dup of #34717 i posted a patch there |
