The online product page to Berkeley DB XML is http://www.sleepycat.com/products/xml.shtml . DBXML 1.1.0 depends on Berkeley DB 4.1.25 (sys-libs/db-4.1.25 is masked) Apache Xerces-C 2.2.0 (dev-libs/xerces-c-2.3.0-r2 is masked and unstable) Pathan 1.2 Reproducible: Always Steps to Reproduce:
i'm working on an ebuild for berkeyley xml db. I'm not really very sure of what i'm doing, but i figure if i can submit an initial ebuild, someone can along and fix it up. i submitted an ebuild for Pathan 1.2.2 as bug #42213. sys-libs/db-4.1.25_p1-r3 is unmasked now. dev-libs/xerces-c-2.4.0-r1 is unmasked and stable now. so the dependancies for Berkeley Xml DB are met, but i still cannot get it to build properly. i ran into some trouble early on having multiple slotted versions of sys-libs/db, so i patched configure so i could tell it which version to use. As far as i can tell, db-4.1.25 has two header files that other versions ( earlier and later ) don't have. These are cxx_common.h and cxx_except.h. I had to make symlinks from /usr/include/db4.1 to /usr/include in order to get configure to complete. After that it was able to start compiling, but it bombs out with undefined references to extern functions from /usr/lib/libdb_cxx-4.1.la. output looks like this: g++ -o .libs/dbxml_dump .libs/dbxml_dump.o ./.libs/libdbxml-1.2.so -L/usr/i686- pc-linux-gnu/bin -L/usr/i686-pc-linux-gnu/lib -L/usr/lib/gcc-lib/i686-pc-linux-g nu/../../../i686-pc-linux-gnu/lib /usr/lib/libdb_cxx-4.1.la /usr/lib/libpathan.l a /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so -L/usr/lib -lxerces-c -l pthread -Wl,--rpath -Wl,/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2 -Wl,--rpath -W l,/usr/lib ./.libs/libdbxml-1.2.so: undefined reference to `__db_getlong' ./.libs/libdbxml-1.2.so: undefined reference to `__db_prheader' ./.libs/libdbxml-1.2.so: undefined reference to `__db_prfooter' ./.libs/libdbxml-1.2.so: undefined reference to `__db_prdbt' ./.libs/libdbxml-1.2.so: undefined reference to `__db_getulong' ./.libs/libdbxml-1.2.so: undefined reference to `__os_clock' collect2: ld returned 1 exit status config.log mentions: /usr/lib/libdb_cxx-4.1.la: file not recognized: File format not recognized that's as far as i was able to get so far. any help appreciated :] -ben
Sorry for the spam, but the bdbxml developers are working on this problem now. Check out http://news.gmane.org/group/gmane.comp.db.dbxml.general/last=/force_load=t I'll report back here when we've found a solution.
From the BerkeleyDB XML guys: I've spent some time looking into this problem, and a bit talking with Gentoo. The problem below occurs because the DB XML build is pointing to a Berkeley DB installation that comes from a Gentoo ebuild, rather than building DB as part of DB XML. The Gentoo ebuild for Berkeley DB uses the "--with-uniquename" configuration option, which results in modifying *every* symbol in DB, appending a string -- in this case, "_4002" DB XML needs to use some non-exported DB symbols (for dump/load), which are those below. Because these symbols are not in the public header file, DB XML doesn't see the modified versions, and the errors below result. There are several possible solutions. First, it'd be great if Gentoo's DB build did not use "--with-uniquename," but it's present to solve one of their problems, and unless/until that's solved, it's not an option. So, there are 2 options for workarounds: 1. download/build Berkeley DB, as all other DB XML users do. In fact, DB XML does not recommend using an existing DB installation. It's obviously possible, but can be prone to version skew problems. 2. modify DB XML source to add #define statements that will change the references to the symbols below to look like those in the modified Berkeley DB installation. This means knowing the mangling, and modifying one or two DB XML files. While this will work, it's also sensitive to any reinstallation of DB. Option (1) is simplest, and safest. It probably means installing Berkeley DB (use 4.2.52, plus current patches) in a non-standard location, which is fine. Let me see if I can get Paul to comment on this here...
If it is true that it is probably best to have a private db library for db-xml, then it might be an idea to have it use a static version. By using a link script (creating a libdb.so file that makes the linker include libdb.a) it could even be done without db-xml ever knowing about it. As a sidenote, I have suggested that the berkeley db would include an autoconf test for checking for berkeley db. The current detection scripts in use are of varying quality and only a few are really working for the future, one standard script could solve many configure bugs. Of course that does not solve the hidden symbols issue in db-xml, but I think we could come up with a way to make those available too automatically with the right symbol names.
Would like to see this package in Gentoo, as I'd like to play with it: Looks some very interessting project, maybe also for portage itself.
As I'm here about to install dbxml on yet another gentoo system I thought I'd ping this bug to see if any progress has been made in the last three years. Is there anyone this bug can be assigned to who may push it through more quickly? Any half-done patches that can be submitted?
(In reply to comment #6) > As I'm here about to install dbxml on yet another gentoo system I thought I'd > ping this bug to see if any progress has been made in the last three years. > > Is there anyone this bug can be assigned to who may push it through more > quickly? Any half-done patches that can be submitted? > I'm also interested in installing dbxml on my Gentoo system. Would you please post any info on how you've gone about it? Specifically, how can I make the python bsddb3 module work with dbxml? The Sleepycat web site says that bsddb3 has to be compiled against the version of Berkeley DB that dbxml is using, so if I install DB and DBXML manually in a nonstandard location, is it possible to use the Portage-installed bsddb3, or do I have to re-install that manually as well?
To install on Gentoo just follow the normal instructions: build using the build script and don't worry about linking to existing libraries. That's my adivse.
Any progress? I was toying with the idea of working on an ebuild myself. Is there any objection to building DBXML the normal way, linking against a private build of the various libraries (bdb, etc)?
*** Bug 60519 has been marked as a duplicate of this bug. ***
Created attachment 112198 [details] dbxml-2.3.10.ebuild This ebuild is working fine for me, though others have criticisms of it. It relies on xqilla-1.0.1, for which a proposed ebuild can be found, for example, in bug #167937
Comment on attachment 112198 [details] dbxml-2.3.10.ebuild Sunrise ebuilds have eclipsed this one
If you can find a maintainer for this, feel free to reopen. Until then, in sunrise overlay and as such closing UPSTREAM.
Reopening since xqilla is now in the tree and I plan to commit this soon...
Created attachment 154843 [details] dbxml-2.4.13.ebuild I've attached my current version of the ebuild vor dbxml 2.3.14+p1. It builds for "-java". But not for "-python", and "-perl" is untested. It seems to work at runtime for x86 (tested by uses by a custom java webapplication), but in the moment i got a "segmentation fault" at startup of dbxml on commandline.
Created attachment 154845 [details] tail of "strace dbxml" on amd64 and x86 but in the moment i got a "segmentation fault" at startup of dbxml on commandline ... ... on amd64. And it breaks the JVM, too. I made an "strace dbxml" on both and attached the difference at tail. It seems, that the amd64 breaks on some open-call for "DB_CONFIG". Note, that a simple "dbxml -?" will work, but a "dbxml -v" will break with Attempting to join environment: . Unable to join environment ., creating a DB_PRIVATE environment Segmentation fault
Good news! The problem on amd64 is traced down the the iconv support of dev-libs/xerces-c. Compiling this without iconv will make dbxml usable for me. It's the same with the dedicated samples within the xerces-c tarball (which are ignored to compile by the Gentoo ebuild) From that, it's not directly related to the dbxml sources or my proposal for a dbxml-2.4.13.ebuild. Note, that i just have need the java USE-flag; the perl and python USEs still need care and feeding. greetings Guido
Even better news (?) I just received the message, that the problems with iconv should have been fixed in Xerces-C V2.9 (and upcoming 3.0), see (http://issues.apache.org/jira/browse/XERCESC-1809?focusedCommentId=12606316#action_12606316) I'll try to bump the xerces-c ebuild and send it to Tiziano. Guido
Finally done.
