s...@feb17.org writes: > A little more information on this. I have probably rebuilt svn about 20 > times tonight from scratch, with > latest source from repository, and after upgrading libtools, autoconf, apr > etc. It failed the make check > tests every time. I finally tried a minimal configure with just the packages > needed to get it to build, > > e.g. > > ./configure --with-apr=/tools/apr > --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ > --with-sqlite=/tools/sqlite-3.7.10 > > > versus: > > ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr > --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ > --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 > --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25
>From tests.log: > svn_tests: E200004: While reading representation offsets for node-revision > '0.0.t0-0': > svn_tests: E200004: Could not convert '%ld' into a number > FAIL: lt-client-test 3: test svn_client_patch That looks like an APR problem, apr_snprintf appears to have output a literal "%ld" rather than interpreting it as an format specifier. I don't know what would cause that, perhaps APR was built with the wrong options? Something to do with 32/64 bit support? Or large file support? APR is a dependency of both Subversion and Apache and they need to use APRs that are compatible, in almost all cases that means Apache and Subversion using the same APR. --with-apxs is the flag that causes Subversion to build with Apache so my first guess is that you have multiple APRs that are incompatible. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
