On my system, subversion is built and linked against sys-libs/db:4.8 * Using: Berkeley DB 4.8 ./configure [...] --with-berkeley-db=db.h:/usr/include/db4.8::db-4.8 [...] [...]libtool [...] -ldb-4.8 [...] (2x) Nevertheless, the compiler invocations mostly list both -I/usr/include/db4.7 and -I/usr/include/db4.8 in this order, causing the 4.7 header files to be used instead. This causes trouble at runtime: $ svnadmin help svnadmin: Bad database version: compiled with 4.7.25, running against 4.8.24 $ svnlook help svnlook: Bad database version: compiled with 4.7.25, running against 4.8.24 Comparing the definition of INCLUDES in Makefile and Makefile.in I found the cause to be SVN_APRUTIL_INCLUDES=' -I/usr/include/apr-1 -I/usr/include/db4.7' which configure finds from executing "/usr/bin/apu-1-config --includes". Looking at the ebuild, I find that there is already a check there to catch this kind of issue. It fails to work for me, though: $ scanelf -nq /usr/lib/libaprutil-1.so.0 libexpat.so.1,libapr-1.so.0,libuuid.so.1,librt.so.1,libcrypt.so.1,libpthread.so.0,libdl.so.2,libc.so.6 /usr/lib/libaprutil-1.so.0 As you can see, libaprutil-1 doesn't link against libdb at all. Maybe this is beause I'm using -Wl,--as-needed. In any case, it seems that this attempt to determine the db version used by apr-util doesn't work reliably. Instead I suggest you depend on apu-1-config just as the configure script does.
Created attachment 209086 [details, diff] bdb version from apu-1-config This patch uses the apu-1-config script to determine the db version apr-util is using. I've decided to use the --includes output, not the --libs or similar, because the includes determine the checks svn will perform at runtime, and because the includes pattern is hardcoded in the --berkley-db configure switch in the ebuild, so that if this ever changes, the ebuild will have to be modified in any case. I've also changed the logic to always use the version from berkley-db instead of the latest one if SVN_BDB_VERSION isn't set. I assume that using that version is what users want, and that forcing him to configure this manually serves little purpose. The possibility to set this manually still remains.
I see logic in the ebuild to deal with at least part of this; please file a new bug against 1.6.17 or 1.6.17-r2 if this is still an issue. My apologies for the complete lack of response here... I only just picked Subversion up as maintainer and would like a clean slate if that is okay with you.
(In reply to comment #2) > I see logic in the ebuild to deal with at least part of this; please file a new > bug against 1.6.17 or 1.6.17-r2 if this is still an issue. My apologies for the > complete lack of response here... I only just picked Subversion up as > maintainer and would like a clean slate if that is okay with you. Looking at the 1.6.17-r1 ebuild, the code in questions still looks exactly like it used to before my patch. It has still the same brokenness about using scanelf to determine the correct version, which provably still doesn't work for me. So I'd say the problem largely remains. I currently cannot reproduce the issue completely, as my apr-util package is currently built against db-2.8 as well. So I'd have to downgrade db, possibly breaking a lot of stuff, then remerge apr and apr-util, in order to actually produce a runtime problem. Do you accept this as enough reason to deal with this bug, or do I really have to proove it to you in full detail? And why file a new report, when simply adjusting the subject of this one has the same effect, and avoids the trouble of duplicating the problem description, duplicating the atachment, and possibly duplicate discussions as well one day? For reference: original subject was: "dev-vcs/subversion-1.6.6 and dev-libs/apr-util-1.3.9: inconsistent sys-libs/db versions"
Patch no longer applies; bug reporter apparently unwilling to address. Closing.
Created attachment 284239 [details, diff] bdb version from apu-1-config Updated patch to take change from ${ROOT} to ${EROOT} into account.
(In reply to comment #4) > Patch no longer applies; bug reporter apparently unwilling to address. Closing. You misunderstood me. I'm perfectly willing to address the fact that the patch no longer applies; I wasn't even aware of that fact as the code looks almost the same. The only change which kept the patch from applying automatically is the fact that the scanelf magic now works on EROOT instead of ROOT. Fixed that in comment #5. I'm also willing to reproduce the original issue, if you absolutely insist on that. But as the scanelf magic currently in the ebuild obviously does not work, I'd consider the ebuild broken even without the db misconfiguration actually exposed. To show that the scanelf thingy is broken, simply take the code used to compute apu_bdb_version and run it on the comand line: $ scanelf -nq "/usr/lib64/libaprutil-1.so.0" | \ grep -Eo "libdb-[[:digit:]]+\.[[:digit:]]+" | \ sed -e "s/libdb-\(.*\)/\1/" (no output) $ scanelf -nq "/usr/lib64/libaprutil-1.so.0" libexpat.so.1,libapr-1.so.0,libuuid.so.1,librt.so.1,libcrypt.so.1,libpthread.so.0,libdl.so.2,libc.so.6 /usr/lib64/libaprutil-1.so.0 (no libdb)
+*subversion-1.6.17-r4 (22 Aug 2011) + + 22 Aug 2011; Tony Vroon <chainsaw@gentoo.org> -subversion-1.6.17-r2.ebuild, + +subversion-1.6.17-r4.ebuild: + Automatically match DBD version to what libapr was built with; idea & code by + Martin von Gagern in bug #291624. Removed -j1 from where it does not seem to + be required. Tested on a dual hex-core system with -j12; please file a bug if + you can make it fail. Removed old ebuild.
