currently we have an "issue" with regards to how sys-devel/db installs its headers. This breaks pam_userdb and other things in nasty ways. 1) db 4.0.x and 4.1.25 collide with headers-vs-symlinks. 2) several others claim to be the db 1.85 headers This has caused some pretty bad breakage for systems I maintain (production level), and testing. Now I wonder how it can be resolved. Reproducible: Always Steps to Reproduce: 1. 2. 3.
about 1) If you want to access particular headers use the /usr/include/db4 or /usr/include/db4.1 include statements. This should work. If it doesn't please specify more clearly what exactly the issue is, and which files it concerns about 2) db allows building 1.85 compatibility which of course also includes header files. As we have paralel db versions each version provides it's own db1.85 headers. If you don't want to use the latest db version also make sure that the application uses -ldb-4.0 (for example) instead of -ldb
PAM adding faulty module: /lib/security/pam_userdb.so PAM unable to dlopen(/lib/security/pam_userdb.so) PAM [dlerror: /lib/security/pam_userdb.so: undefined symbol: dbm_firstkey] this comes from linking vs 1 version and getting symbols from another. Forcing a rebuild and it gets yet another set of symbols : PAM [dlerror: /lib/security/pam_userdb.so: undefined symbol: __db_ndbm_close_4000] PAM adding faulty module: /lib/security/pam_userdb.so PAM unable to dlopen(/lib/security/pam_userdb.so) This is -only- solved by forcibly removing all other versions of db than the latest, rebuilding that because removing the other versions killed the headerfiles from db 4.1.25, Then rebuiling pam. So yes, its a real issue when the same compatible headers are owned by several packages.
I will look at the PAM system and how it decides which db to use. Pam seems to someway have it's own db. At least the db directory is present in the workdir.
From what I can see now (looking at the makefiles of the userdb module and the ebuild) there is no way in which the userdb module actually gets linked with any db module. Neither does the custom db that the ebuild tries to install get used. I'll try to create a static db for use in the pam ebuild's userdb module.
Ok, I located the problem. The cause was an incomplete post-configure hack to have pam_userdb not use ndbm (aka db_1.85). The hack edited the makefiles but did not edit the configuration header file. As such the pam_userdb.c included ndbm.h and from that include file /usr/include/db1/db.h while the intent of the makefiles was to link against the internal static db. By now applying the hack to also correct the configuration includefile, things should start to work. I'm now compiling a new version that I will commit as -r1 (testing) when the pam module loads (I don't have userdb setup so I cannot check beyond that, but as userdb is currently not working at all this should not be an issue). btw. I have 4 different db versions installed so you can trust that it will work with all kinds of db versions instaled. Note that the original problem is only a conflict with db1 not any of the db3 or db4 versions.
okay, Thats a good thing :) Btw, something I wondered about here, when/if I decide to clean out db 4.0 (oops) Then would the compability links be removed or not? I'm curious as this would sorta hamper things.. Good that the pam_userdb was solved, my local hack was fairly brutal. (what put me off at this was that it was different symbols missing when I had different versions installed..)
I'm not planning on phasing out db-4.0.14 within a year (probably longer) (note we still have db-3.2). Also those compatibility links exist so that naive applications can automatically link to the latest db version. If any application wants to link to a specific version there are two things that need to be done: It must specify -I/usr/include/db<version> and it must link using -ldb-<version>. The -ldb-<version> is the standard approach to linking to specific library versions, while /usr/inlude/db<version> is sortof standard (missing any standard approach from the sleepycat folks). Some weeks ago the people from sleepycat contacted me about the setup in connection with dbxml. I suggested them to write an autoconf macro that would allow packages to easilly find a specific db version if they want or general db in other cases. This would also include header/library synchronization. Most configure scripts perform an extremely lousy job at this and a provided autoconf macro could help those upstream developers to fix things up while also saving time because of a standard solution. btw. I solved what was going wrong by first looking at what the makefile did for compiling pam_userdb.so, and then running it manually, but replacing -c with -E such as to get the result of the preprocessor. As the preprocessor adds markers which files it loaded, it was possible to see where things went wrong.
oh, Autoconf.. .*shudder* (I dislike it almost as much as libtool.. erm. s/dislike/loathe/g ) however I agree that some predefined macros would remove a lot of headaches here And thanks for the debugging tip, much appreciated.
Yes, they can be horible indeed :-(, anyway, I'll close this now as pam_userdb is working again. Please tell me if you meet other db issues.
Forgot to fix it
