svn_at_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
Received on 2012-03-13 13:25:23 CET