Subversion developers have warned that BDB-4.1 sometimes causes repositories to break. 4.2 is not known to have this problem. Will it be possible to update the bdb version required for svn? Reproducible: Always Steps to Reproduce: N/A Actual Results: N/A
I'll unmask db-4.2 now. I will not yet make subversion depend on it (so I can mask it again when problems arise), but will do so probably with the 1.1 release
Can I test to see if that changes my problems? How do I make sure that subversion links against the 4.2 BDB? (This is not a production repos,so I think I can do that reasonably safe.) The problem *does* occur on another svn server I manage, which is a production server. I'm not too keen on experimenting with db there however.
Before you start, you might want to dump the repository. After that, merge db-4.2. If things function properly then subversion should just pick up db-4.2. You can check it from the output of the configure script.
I have recently merged DB 4.2; now, when trying to upgrade subversion to 1.0.6,I get the following error: Calculating dependencies ...done! >>> emerge (1 of 1) dev-util/subversion-1.0.6 to / >>> md5 src_uri ;-) subversion-1.0.6.tar.bz2 berkdb apache2 * The apache2 subversion module will be built, and libapr from the * apache package will be used instead of the included. >>> Unpacking source... >>> Unpacking subversion-1.0.6.tar.bz2 to /var/tmp/portage/subversion-1.0.6/work * Applying subversion-db4.patch... [ ok ] * Patching ${S}/apr/build/ltmain.sh... * Applying portage-1.4.1.patch... * Applying relink-1.4.3.patch... * Applying sed-1.4.3.patch... * Applying tmp-1.3.5.patch... * Patching ${S}/neon/ltmain.sh... * Applying portage-1.4.1.patch... * Applying max_cmd_len-1.5.0.patch... * Patching ${S}/ac-helpers/ltmain.sh... * Applying portage-1.4.1.patch... * Applying relink-1.4.3.patch... * Applying sed-1.4.3.patch... * Applying tmp-1.3.5.patch... * Patching ${S}/apr-util/xml/expat/conftools/ltmain.sh... * Applying portage-1.4.1.patch... * Applying relink-1.4.3.patch... * Applying sed-1.4.3.patch... * Applying tmp-1.3.5.patch... >>> Source unpacked. ssl ssl apache2 apache2 berkdb berkdb python python configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. Configuring Subversion 1.0.6 creating config.nice checking for i686-pc-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking whether ln -s works... yes configure: Apache Portable Runtime (APR) library configuration checking for APR... yes checking APR version... 0.9.5 configure: Apache Portable Runtime Utility (APRUTIL) library configuration checking for APR-util... yes checking APR-UTIL version... 0.9.5 configuring libtool now checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for ld used by GCC... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... nm checking for a sed that does not truncate output... /bin/sed checking how to recognise dependent libraries... pass_all checking command to parse nm output... ok checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking for i686-pc-linux-gnu-strip... no checking for strip... strip checking for objdir... .libs checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking whether the linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether -lc should be explicitly linked in... no creating libtool configure: checking neon library checking neon library version... 0.24.7 checking for static Apache module support... no checking for Apache module support via DSO through APXS... found at /usr/sbin/apxs2 checking httpd version... recent enough checking for socket in -lsocket... no checking for availability of Berkeley DB... no configure: error: Berkeley DB 4.0.14 wasn't found. !!! ERROR: dev-util/subversion-1.0.6 failed. !!! Function econf, Line 362, Exitcode 1 !!! econf failed
Hmmm. This happens at my machine too. I have not actually checked it, but this should be fixed by recompiling apache-2. The problem is caused by a header/lib mismatch. Please report whether that works
Ok, recompiling apache at my machine worked to make subversion work. I guess I'll need to add a check to the ebuild so it is clear how to solve the problem.
Recompiling apache worked for me as well. Thanks!
Recompiling apache now, fingers crossed :)
I guess it is fixed now
