some details about this bug -- are you happy yet? Reproducible: Always Steps to Reproduce: 1. emerge xemacs 2. enjoy your bug 3. Actual Results: Normal build until compiling src/database.c, then gcc -c -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wdeclaration-after-statement -Wunused-parameter -g -O3 -fno-strict-aliasing -Demacs -I. -I/playpen/src/XEmacs/xemacs/src -DHAVE_CONFIG_H -I/usr/include/freetype2 /playpen/src/XEmacs/xemacs/src/database.c In file included from /usr/include/ndbm.h:42:0, from /playpen/src/XEmacs/xemacs/src/database.c:87: /usr/include/db1/db.h:77:3: error: conflicting types for 'DBT' /usr/include/db.h:142:42: note: previous declaration of 'DBT' was here /usr/include/db1/db.h:92:16: error: redeclaration of enumerator 'DB_BTREE' /usr/include/db.h:1103:11: note: previous definition of 'DB_BTREE' was here /usr/include/db1/db.h:92:26: error: redeclaration of enumerator 'DB_HASH' /usr/include/db.h:1104:10: note: previous definition of 'DB_HASH' was here /usr/include/db1/db.h:92:35: error: redeclaration of enumerator 'DB_RECNO' /usr/include/db.h:1105:11: note: previous definition of 'DB_RECNO' was here /usr/include/db1/db.h:92:46: error: conflicting types for 'DBTYPE' /usr/include/db.h:1108:3: note: previous declaration of 'DBTYPE' was here /usr/include/db1/db.h:118:16: error: redefinition of 'struct __db' /usr/include/db.h:138:8: note: originally defined here /usr/include/db1/db.h:128:3: error: conflicting types for 'DB' /usr/include/db.h:138:35: note: previous declaration of 'DB' was here /playpen/src/XEmacs/xemacs/src/database.c: In function 'berkdb_get': /playpen/src/XEmacs/xemacs/src/database.c:459:3: warning: passing argument 4 of 'db->db_handle->get' makes integer from pointer without a cast /playpen/src/XEmacs/xemacs/src/database.c:459:3: note: expected 'u_int' but argument is of type 'struct DBT *' /playpen/src/XEmacs/xemacs/src/database.c:459:3: error: too many arguments to function 'db->db_handle->get' /playpen/src/XEmacs/xemacs/src/database.c: In function 'berkdb_put': /playpen/src/XEmacs/xemacs/src/database.c:498:11: warning: passing argument 4 of 'db->db_handle->put' makes integer from pointer without a cast /playpen/src/XEmacs/xemacs/src/database.c:498:11: note: expected 'u_int' but argument is of type 'struct DBT *' /playpen/src/XEmacs/xemacs/src/database.c:498:11: error: too many arguments to function 'db->db_handle->put' /playpen/src/XEmacs/xemacs/src/database.c: In function 'berkdb_remove': /playpen/src/XEmacs/xemacs/src/database.c:520:3: warning: passing argument 3 of 'db->db_handle->del' makes integer from pointer without a cast /playpen/src/XEmacs/xemacs/src/database.c:520:3: note: expected 'u_int' but argument is of type 'struct DBT *' /playpen/src/XEmacs/xemacs/src/database.c:520:3: error: too many arguments to function 'db->db_handle->del' /playpen/src/XEmacs/xemacs/src/database.c: In function 'berkdb_map': /playpen/src/XEmacs/xemacs/src/database.c:562:17: error: 'DB' has no member named 'cursor' /playpen/src/XEmacs/xemacs/src/database.c:566:5: warning: passing argument 2 of 'dbcp->c_get' from incompatible pointer type /playpen/src/XEmacs/xemacs/src/database.c:566:5: note: expected 'struct DBT *' but argument is of type 'struct DBT *' /playpen/src/XEmacs/xemacs/src/database.c:566:5: warning: passing argument 3 of 'dbcp->c_get' from incompatible pointer type /playpen/src/XEmacs/xemacs/src/database.c:566:5: note: expected 'struct DBT *' but argument is of type 'struct DBT *' /playpen/src/XEmacs/xemacs/src/database.c:568:3: warning: passing argument 2 of 'dbcp->c_get' from incompatible pointer type /playpen/src/XEmacs/xemacs/src/database.c:568:3: note: expected 'struct DBT *' but argument is of type 'struct DBT *' /playpen/src/XEmacs/xemacs/src/database.c:568:3: warning: passing argument 3 of 'dbcp->c_get' from incompatible pointer type /playpen/src/XEmacs/xemacs/src/database.c:568:3: note: expected 'struct DBT *' but argument is of type 'struct DBT *' /playpen/src/XEmacs/xemacs/src/database.c: In function 'berkdb_close': /playpen/src/XEmacs/xemacs/src/database.c:591:7: error: too many arguments to function 'db->db_handle->close' /playpen/src/XEmacs/xemacs/src/database.c: In function 'Fopen_database': /playpen/src/XEmacs/xemacs/src/database.c:752:7: warning: passing argument 1 of 'db_create' from incompatible pointer type /usr/include/db.h:2639:5: note: expected 'struct DB **' but argument is of type 'struct DB **' /playpen/src/XEmacs/xemacs/src/database.c:760:21: error: 'DB' has no member named 'open' /playpen/src/XEmacs/xemacs/src/database.c:765:11: error: too many arguments to function 'dbase->close' make[1]: *** [database.o] Error 1 make[1]: Leaving directory `/playpen/src/XEmacs/xemacs/dbm/src' make: *** [src] Error 2 Expected Results: built and installed XEmacs I don't know if this is Gentoo or Linux specific, I don't have another platform where both Berkeley db and gdbm are in use. I doubt upstream will be able to fix quickly. Probably the right solution is to break up Berkeley and dbm support into separate modules, but we don't have anybody who is particularly familiar with these databases active at this time. Probably the best thing to do is to pick one of the use flags to disable by default.
(In reply to comment #0) > I doubt upstream will be able to fix quickly. Probably the right solution is > to break up Berkeley and dbm support into separate modules, but we don't have > anybody who is particularly familiar with these databases active at this time. I guess you could detect multiple selected backends and raise an error in ./configure. > Probably the best thing to do is to pick one of the use flags to disable by > default. I could either raise an error when both are selected, or pick one. I guess that we should then pick berkdb over gdbm?
I've just tried to reproduce this, but compiling with USE="berkdb gdbm" works fine for me, and the resulting binary is linked to both berkdb and gdbm. So something else must be going on here. I notice in the trace that it refers to /usr/include/ndbm.h, but on Gentoo this file should be at /usr/include/gdbm/ndbm.h. Which version of gdbm do you have installed? What package owns the /usr/include/ndbm.h file?
(In reply to comment #2) > I notice in the trace that it refers to /usr/include/ndbm.h, but on Gentoo this > file should be at /usr/include/gdbm/ndbm.h. Which version of gdbm do you have > installed? What package owns the /usr/include/ndbm.h file? $ equery b /usr/include/ndbm.h * Searching for /usr/include/ndbm.h ... sys-libs/db-1.85-r3 (/usr/include/ndbm.h -> db1/ndbm.h) sys-libs/db-1.85-r3 (/usr/include/db1/ndbm.h) $ emerge -s gdbm Searching... [ Results for search key : gdbm ] [ Applications found : 1 ] * sys-libs/gdbm Latest version available: 1.8.3-r4 Latest version installed: 1.8.3-r4 Size of files: 223 kB Homepage: http://www.gnu.org/software/gdbm/gdbm.html Description: Standard GNU database libraries License: GPL-2 $ I tried to query for dependencies on db-1.85, but got what seem to be nonsense results even with a fully qualified =atom: $ equery d =sys-libs/db-1.85-r3 * These packages depend on sys-libs/db-1.85-r3: app-editors/xemacs-21.5.29-r2 (berkdb ? sys-libs/db) dev-lang/perl-5.12.3-r1 (berkdb ? sys-libs/db) dev-lang/python-2.4.6 (berkdb ? sys-libs/db:4.4) (berkdb ? sys-libs/db:4.3) (berkdb ? sys-libs/db:4.2) dev-lang/python-2.5.4-r4 (berkdb ? sys-libs/db:4.5) (berkdb ? sys-libs/db:4.4) (berkdb ? sys-libs/db:4.3) (berkdb ? sys-libs/db:4.2) dev-lang/python-2.7.1-r1 (berkdb ? sys-libs/db:4.8) (berkdb ? sys-libs/db:4.7) (berkdb ? sys-libs/db:4.6) (berkdb ? sys-libs/db:4.5) (berkdb ? sys-libs/db:4.4) (berkdb ? sys-libs/db:4.3) (berkdb ? sys-libs/db:4.2) dev-lang/ruby-1.8.7_p334 (berkdb ? sys-libs/db) dev-libs/redland-1.0.10-r2 (berkdb ? sys-libs/db) net-nds/openldap-2.4.24 (berkdb ? sys-libs/db) perl-core/DB_File-1.822.0 (sys-libs/db) sys-apps/iproute2-2.6.37 (berkdb ? sys-libs/db) sys-libs/gdbm-1.8.3-r4 (berkdb ? sys-libs/db) sys-libs/pam-1.1.3 (berkdb ? sys-libs/db) $
(In reply to comment #3) > (In reply to comment #2) > > > I notice in the trace that it refers to /usr/include/ndbm.h, [...] > > $ equery b /usr/include/ndbm.h > * Searching for /usr/include/ndbm.h ... > sys-libs/db-1.85-r3 (/usr/include/ndbm.h -> db1/ndbm.h) > sys-libs/db-1.85-r3 (/usr/include/db1/ndbm.h) This seems crazy to me. Anybody who wants to use db-1.85 in this day and age should have to ask for it directly, and it should no way be providing system includes for other programs.
I've now fixed this in xemacs-5.2.31 by requesting sys-libs/db-4 or better, and by blocking on older versions. This should avoid this particular situation, where sys-libs/db-1.85 may still be around due to it being slotted.
(In reply to comment #5) > I've now fixed this in xemacs-5.2.31 by requesting sys-libs/db-4 or better, and > by blocking on older versions. This should avoid this particular situation, > where sys-libs/db-1.85 may still be around due to it being slotted. Is this what's expected, or should the system work around this automatically? emerge -p -u world sez (among other things): [blocks B ] <sys-libs/db-4 ("<sys-libs/db-4" is blocking app-editors/xemacs-21.5.31) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-libs/db-1.85-r3, installed) pulled in by sys-libs/db:1 required by @selected emerge -s db sez (among other things): * sys-libs/db Latest version available: 4.8.30 Latest version installed: 4.8.30 Size of files: 22,350 kB Homepage: http://www.oracle.com/technology/software/products/berkeley-db/index.html Description: Oracle Berkeley DB License: OracleDB
(In reply to comment #6) > emerge -p -u world sez (among other things): > > [blocks B ] <sys-libs/db-4 ("<sys-libs/db-4" is blocking > app-editors/xemacs-21.5.31) This is xemacs telling you that it can't built with those old db version on the system. > * Error: The above package list contains packages which cannot be > * installed at the same time on the same system. > > (sys-libs/db-1.85-r3, installed) pulled in by > sys-libs/db:1 required by @selected This is portage telling you that sys-libs/db:1 is in the @selected set and thus needs to be pulled in. It can't resolve that automatically, so you should either turn off berkdb support for xemacs, or not request sys-libs/db:1 to be present on the system.
(In reply to comment #7) > It can't resolve that automatically, so you should either turn off berkdb > support for xemacs, This is not about me. I know that, but emerge doesn't tell anybody else about it. How is the user supposed to figure that out from the message displayed by emerge? > or not request sys-libs/db:1 to be present on the system. But *I* did *not* request db:1. Something else did, and it's non-trivial to determine whether it's safe to remove it. Specifically, several attempts to specify the version to "equery depends" were ignored, and returned many packages, of which at least xemacs conflicts with db:1. Syntax for doing this is nowhere documented that I can find.
(In reply to comment #8) > (In reply to comment #7) > > This is not about me. I know that, but emerge doesn't tell anybody else about > it. How is the user supposed to figure that out from the message displayed by > emerge? I don't think there is anything in the ebuild that I can do to make this more clear. > > or not request sys-libs/db:1 to be present on the system. > > But *I* did *not* request db:1. Something else did, and it's non-trivial to > determine whether it's safe to remove it. Try "emerge -pv --depclean sys-libs/db:1". That should either remove it, or tell you specific dependencies.
