After emerging apr-1.0.0 ( http://bugs.gentoo.org/show_bug.cgi?id=61045 ), I can finally try to build subversion-1.1.0_rc*. Unmasked subversion-1.1.0_rc2.ebuild, copied to portage overlay, and made the following 1-line diff to handle the new apr-config locations: --- /usr/portage/dev-util/subversion/subversion-1.1.0_rc2.ebuild 2004-09-01 07:07:08.000000000 -0400 +++ /usr/local/portage/dev-util/subversion/subversion-1.1.0_rc2.ebuild 2004-09-04 14:31:07.302491184 -0400 @@ -97,7 +97,7 @@ use ssl || myconf="${myconf} --without-ssl" use apache2 && myconf="${myconf} --with-apxs=/usr/sbin/apxs2 \ - --with-apr=/usr --with-apr-util=/usr" + --with-apr=/usr/bin/apr-1-config --with-apr-util=/usr/bin/apu-1-config" use apache2 || myconf="${myconf} --without-apxs" use berkdb && myconf="${myconf} --with-berkeley-db" Emerging subversion now will fail with the following error: (...) cd subversion/tests/libsvn_repos && /bin/sh /var/tmp/portage/subversion-1.1.0_rc2/work/subversion-1.1.0-rc2/libtool --silent --mode=link gcc -L/var/tmp/portage/subversion-1.1.0_rc2/image//usr/lib -O2 -march=athlon-xp -mcpu=i686 -pipe -fomit-frame-pointer -pthread -DNEON_ZLIB -DNEON_SSL -rpath /usr/lib -o md5args md5args.o ../../../subversion/libsvn_subr/libsvn_subr-1.la /usr/lib/libaprutil-1.la -lgdbm -ldb-4.2 -lexpat /usr/lib/libapr-1.la -lrt -lcrypt -lpthread -ldl cd subversion/tests/libsvn_delta && /bin/sh /var/tmp/portage/subversion-1.1.0_rc2/work/subversion-1.1.0-rc2/libtool --silent --mode=link gcc -L/var/tmp/portage/subversion-1.1.0_rc2/image//usr/lib -O2 -march=athlon-xp -mcpu=i686 -pipe -fomit-frame-pointer -pthread -DNEON_ZLIB -DNEON_SSL -rpath /usr/lib -o svndiff-test svndiff-test.o ../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../subversion/libsvn_subr/libsvn_subr-1.la /usr/lib/libaprutil-1.la -lgdbm -ldb-4.2 -lexpat /usr/lib/libapr-1.la -lrt -lcrypt -lpthread -ldl ../../../subversion/libsvn_subr/.libs/libsvn_subr-1.so: undefined reference to `APR_STATUS_IS_SUCCESS' collect2: ld returned 1 exit status make: *** [subversion/tests/libsvn_repos/md5args] Error 1 make: *** Waiting for unfinished jobs.... svndiff-test.o(.text+0x5d): In function `main': : undefined reference to `APR_STATUS_IS_SUCCESS' svndiff-test.o(.text+0x95): In function `main': : undefined reference to `APR_STATUS_IS_SUCCESS' collect2: ld returned 1 exit status make: *** [subversion/tests/libsvn_delta/svndiff-test] Error 1 !!! ERROR: dev-util/subversion-1.1.0_rc2 failed. !!! Function src_compile, Line 120, Exitcode 2 !!! make of subversion failed Here is the config part of the ebuild, if this helps anyone spot the problem: >>> emerge (1 of 1) dev-util/subversion-1.1.0_rc2 to / >>> md5 src_uri ;-) subversion-1.1.0-rc2.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.1.0-rc2.tar.bz2 to /var/tmp/portage/subversion-1.1.0_rc2/work * Applying subversion-db4.patch... [ ok ] * Applying subversion-1.1.0-rc2-build.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.1.0 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... 1.0.0 configure: Apache Portable Runtime Utility (APRUTIL) library configuration checking for APR-util... yes checking APR-UTIL version... 1.0.0 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 checking whether libtool needs -no-undefined... no 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... apxs:Error: /usr/bin/apr-config not found!. found at /usr/sbin/apxs2 checking httpd version... recent enough apxs:Error: /usr/bin/apr-config not found!. apxs:Error: /usr/bin/apr-config not found!. checking for socket in -lsocket... no checking for availability of Berkeley DB... yes checking for msgfmt... /usr/bin/msgfmt checking for msgmerge... /usr/bin/msgmerge checking for xgettext... /usr/bin/xgettext checking for library containing bindtextdomain... none required checking for bind_textdomain_codeset... yes checking for ANSI C header files... (cached) yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for working memcmp... yes checking for vprintf... yes checking for _doprnt... no checking for symlink... yes checking for readlink... yes configure: Disabling apache module activation checking for python2... /usr/bin/python2 checking for Python 2.0 or newer checking for JDK... configure: WARNING: no JNI header files found. no checking for perl... /usr/bin/perl configure: Enabled swig binding: perl configure: Enabled swig binding: python configure: Enabled swig binding: java checking for swig... /usr/bin/swig checking swig version... 1.3.21 checking for swig library directory... /usr/lib/swig1.3 configure: Configuring python swig binding checking if swig needs -L for its libraries... checking for Python includes... -I/usr/include/python2.3 checking for compiling Python extensions... gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC checking for linking Python extensions... gcc -pthread -shared checking for linking Python libraries... checking perl version... 5008005 checking for makeinfo... /usr/bin/makeinfo configure: creating ./config.status config.status: creating Makefile config.status: creating svn-config config.status: creating tools/backup/hot-backup.py config.status: creating contrib/client-side/svn_load_dirs.pl config.status: creating tools/hook-scripts/commit-access-control.pl config.status: creating tools/hook-scripts/commit-email.pl config.status: creating tools/hook-scripts/propchange-email.pl config.status: creating subversion/bindings/swig/perl/native/Makefile.PL config.status: creating subversion/svn_private_config.h apache2 /bin/sh /var/tmp/portage/subversion-1.1.0_rc2/work/subversion-1.1.0-rc2/libtool --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -O2 -march=athlon-xp -mcpu=i686 -pipe -fomit-frame-pointer -pthread -DNEON_ZLIB -DNEON_SSL -I./subversion/include -I./subversion -I/usr/include/neon -I/usr/include/apr-1 -I/usr/include/apr-1 -o subversion/libsvn_delta/cancel.lo -c subversion/libsvn_delta/cancel.c (...) Reproducible: Always Steps to Reproduce:
Subversion-devel mailing list provided an explanation and patch: http://article.gmane.org/gmane.comp.version-control.subversion.devel/50344 max bowsher wrote: The APR ABI changed between 0.9.x and 1.x. Since subversion uses apr datatypes in its own public API, and subversion is committed to maintaining ABI compatibility throughout 1.x, subversion is not really meant to build against apr 1.x - apr 0.9.x only. That said, if you are willing to accept that svn-1.x+apr-1.x will be ABI incompatible with 'normal' svn-1.x, we do try to make it work. However, as we are not paying close attention to apr 1.x, sometimes we are slow catching up with changes. This is one of those circumstances. Your options: 1. Build subversion against apr 0.9.x (which can co-exist in the same installation prefix with apr-1.x) 2. Apply the patch appended to this email (which is r10438 of subversion trunk, and is expected to be present in 1.1.0rc3 and later). Max. Index: subversion/libsvn_subr/io.c =================================================================== --- subversion/libsvn_subr/io.c (revision 10437) +++ subversion/libsvn_subr/io.c (revision 10438) <at> <at> -223,7 +223,7 <at> <at> apr_status_t apr_err_2 = apr_stat (&finfo, unique_name_apr, APR_FINFO_TYPE, pool); - if (APR_STATUS_IS_SUCCESS (apr_err_2) + if (!apr_err_2 && (finfo.filetype == APR_DIR)) continue; <at> <at> -308,7 +308,7 <at> <at> apr_status_t apr_err_2 = apr_stat (&finfo, unique_name_apr, APR_FINFO_TYPE, pool); - if (APR_STATUS_IS_SUCCESS (apr_err_2) + if (!apr_err_2 && (finfo.filetype == APR_DIR)) continue; <at> <at> -2383,7 +2383,7 <at> <at> status = apr_dir_is_empty (path_apr, pool); - if (APR_STATUS_IS_SUCCESS (status)) + if (!status) *is_empty_p = TRUE; else if (APR_STATUS_IS_ENOTEMPTY (status)) *is_empty_p = FALSE; Index: subversion/tests/libsvn_delta/svndiff-test.c =================================================================== --- subversion/tests/libsvn_delta/svndiff-test.c (revision 10437) +++ subversion/tests/libsvn_delta/svndiff-test.c (revision 10438) <at> <at> -50,7 +50,7 <at> <at> pool = svn_pool_create (NULL); apr_err = apr_file_open (&source_file, argv[1], (APR_READ | APR_BINARY), APR_OS_DEFAULT, pool); - if (! APR_STATUS_IS_SUCCESS (apr_err)) + if (apr_err) { fprintf (stderr, "unable to open \"%s\" for reading\n", argv[1]); exit (1); <at> <at> -58,7 +58,7 <at> <at> apr_err = apr_file_open (&target_file, argv[2], (APR_READ | APR_BINARY), APR_OS_DEFAULT, pool); - if (! APR_STATUS_IS_SUCCESS (apr_err)) + if (apr_err) { fprintf (stderr, "unable to open \"%s\" for reading\n", argv[2]); exit (1); Index: subversion/tests/libsvn_delta/vdelta-test.c =================================================================== --- subversion/tests/libsvn_delta/vdelta-test.c (revision 10437) +++ subversion/tests/libsvn_delta/vdelta-test.c (revision 10438) <at> <at> -85,7 +85,7 <at> <at> apr_err = apr_file_open (&fp, path, (APR_READ | APR_BINARY), APR_OS_DEFAULT, pool); - if (! APR_STATUS_IS_SUCCESS (apr_err)) + if (apr_err) { fprintf (stderr, "unable to open \"%s\" for reading\n", path); exit (1); Index: subversion/libsvn_ra_svn/cram.c =================================================================== --- subversion/libsvn_ra_svn/cram.c (revision 10437) +++ subversion/libsvn_ra_svn/cram.c (revision 10438) <at> <at> -144,9 +144,9 <at> <at> /* Send a challenge. */ status = make_nonce(&nonce); - if (APR_STATUS_IS_SUCCESS(status)) + if (!status) status = apr_gethostname(hostbuf, sizeof(hostbuf), pool); - if (!APR_STATUS_IS_SUCCESS(status)) + if (status) return fail(conn, pool, "Internal server error in authentication"); challenge = apr_psprintf(pool, "<%" APR_UINT64_T_FMT ".%" APR_TIME_T_FMT " <at> %s>", Index: subversion/libsvn_ra_svn/marshal.c =================================================================== --- subversion/libsvn_ra_svn/marshal.c (revision 10437) +++ subversion/libsvn_ra_svn/marshal.c (revision 10438) <at> <at> -121,7 +121,7 <at> <at> } pfd.p = pool; pfd.reqevents = APR_POLLIN; - return (APR_STATUS_IS_SUCCESS(apr_poll(&pfd, 1, &n, 0)) && n); + return ((apr_poll(&pfd, 1, &n, 0) == APR_SUCCESS) && n); } /* --- WRITE BUFFER MANAGEMENT --- */ Index: subversion/libsvn_fs_fs/fs_fs.c =================================================================== --- subversion/libsvn_fs_fs/fs_fs.c (revision 10437) +++ subversion/libsvn_fs_fs/fs_fs.c (revision 10438) <at> <at> -3268,10 +3268,10 <at> <at> /* Match the perms on the old file to the perms reference file. */ status = apr_stat (&finfo, perms_reference, APR_FINFO_PROT, pool); - if (! APR_STATUS_IS_SUCCESS (status)) + if (status) return svn_error_wrap_apr (status, _("Can't stat '%s'"), perms_reference); status = apr_file_perms_set (old_filename, finfo.protection); - if (! APR_STATUS_IS_SUCCESS (status)) + if (status) return svn_error_wrap_apr (status, _("Can't chmod '%s'"), old_filename); #endif
Why do you insist on using apr instead of using apache2's copy or subversion's own? I'll try to assess the standalone apr for the upcomming 1.1 release, but until now it is unsupported. As you write in the bugreport the 1.0 release of apr is not supposed to be compatible to the 0.9.x releases so it will probably not be official until subversion officially supports the 1.0 branch of apr.
> Why do you insist on using apr instead of using apache2's copy > or subversion's own? The only reason is that I don't yet know how do that within portage. I don't know how to make ebuilds that extract portions of the (apache) tarball and start an emake only in the apr and apr-util subdirectories, treating that as the working sandbox root. There were a lot of things I don't know about portage and the subversion makefile that had to come together to use external apr source. I had just sat down to try and figure that out when the apr-1.0.0 announcement came out. Depending on a newer apr package seemd more expedient. I really just wanted to make the apr issue go away because I'm only using subversion with local file:// repositories right now. I'm eager to use 1.1.0 only to get the symlink versioning support, since have a source tree with many symlinks that needs to get into subversion ASAP.
Well, it is very easy. The subversion tarball contains apr and apr-util. You have two options. You either install apache2 and use it's apr/apu or you let subversion compile and install its own apr/apu. If you want to use the release candidate, just add it to /etc/portage/package.unmask. It should be safe.
> either install apache2 and use it's apr/apu or you let subversion > compile and install its own apr/apu. It hasn't quite worked out that way on my system. I do have apache2 installed. the apr package becomes a dependency of the subversion ebuild if the apache2 USE flag is present. Given the apache2 flag, the subversion ebuild will pull in either the apr-0.9.4 in portage, or the apr-1.0.0 I made in portage overlay. I've been experimenting with dropping the apr package dependency if the apache2 flag is specified. The problem is that subversion's make/conf step can't find the installed apr. Details follow: # emerge -pvDu world [ebuild N ] dev-libs/apr-1.0.0 0 kB [1] [ebuild U ] dev-util/subversion-1.1.0_rc2 [1.0.6] +apache2 +berkdb +emacs -java +perl +python +ssl 0 kB # USE="-apache2" emerge -pvDu subversion These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] dev-util/subversion-1.1.0_rc2 [1.0.6] -apache2 +berkdb +emacs -java +perl +python +ssl 0 kB Running this second form (-apache2) warns about my apache2 installation: * Please note that subversion and apache2 cannot be installed * simultaneously without specifying the apache2 use flag. This is * because subversion installs its own libapr and libapr-util in that * case. Specifying the apache2 useflag will also enable the building of * the apache2 module. However, I do apparently have suitable apr-0.9.5 libraries and headers, installed from my apache2. # locate apr (...) /usr/include/apache2/apr_general.h /usr/include/apache2/apr_support.h /usr/include/apache2/apr_global_mutex.h /usr/include/apache2/apr_hash.h /usr/include/apache2/apr_allocator.h /usr/include/apache2/apr_ldap.h /usr/include/apache2/apr_mmap.h /usr/include/apache2/apr.h /usr/include/apache2/apr_strmatch.h /usr/include/apache2/apr_compat.h /usr/include/apache2/apr_poll.h /usr/include/apache2/apr_reslist.h /usr/include/apache2/apr_errno.h /usr/include/apache2/apr_ring.h /usr/include/apache2/apr_sdbm.h (...) /usr/lib/libaprutil-0.so.0 /usr/lib/libapr-0.so.0 /usr/lib/libapr-0.so.0.9.5 /usr/lib/libaprutil-0.so.0.9.5 (...) There are no use flags that would indicate the libapr-0.9.5 is optional to the apache2 ebuild, so what it we assume libapr will be present if the apache2 package is installed? net-www/apache-2.0.50 +berkdb -debug +doc +gdbm -ipv6 +ldap +ssl -static -threads I make the following diff to the current subversion-1.1.0_rc2.ebuild: # diff /usr/portage/dev-util/subversion/subversion-1.1.0_rc2.ebuild /usr/local/portage/dev-util/subversion/subversion-1.1.0_rc2.ebuild 24,26c24,25 < apache2? ( >=net-www/apache-2.0.49 ) < !apache2? ( !>=net-www/apache-2* ) < !dev-libs/apr --- > apache2? ( >=net-www/apache-2.0.49 > !dev-libs/apr ) 100c99 < --with-apr=/usr --with-apr-util=/usr" --- > --with-apr=/usr/lib --with-apr-util=/usr/lib" The first change does make the subversion ebuild attempt to use apache2's installed apr. However, there is no combination of --with-apr[-util] that I can find to make the conf step find the installed apr. When I had apr-1.0.0, installed, there was a binary apr-1-config and apr-util-1-config in /usr/bin that would give the conf step all the path information it needed. Without an apr-0.9.5 or apr-1.0.0 package, I don't think we get those utilities from the apache install. The only other resource I can think of are these two files: # cat /usr/portage/net-www/apache/files/common/apr-config.layout <Layout Gentoo> prefix: /usr exec_prefix: /usr bindir: /usr/bin sbindir: /usr/sbin libdir: /usr/lib libexecdir: /usr/lib/apache2/modules mandir: /usr/share/man sysconfdir: /etc/apache2/conf datadir: /var/www/localhost installbuilddir: /usr/lib/apache2/build includedir: /usr/include/apache2 localstatedir: /var libsuffix: -${APR_MAJOR_VERSION} </Layout> # cat /usr/portage/net-www/apache/files/common/apr-util-config.layout <Layout Gentoo> prefix: /usr exec_prefix: /usr bindir: /usr/bin sbindir: /usr/sbin libdir: /usr/lib libexecdir: /usr/lib/apache2/modules mandir: /usr/share/man sysconfdir: /etc/apache2/conf datadir: /var/www/localhost installbuilddir: /usr/lib/apache2/build includedir: /usr/include/apache2 localstatedir: /var libsuffix: -${APRUTIL_MAJOR_VERSION} </Layout> But the conf step won't accept them in the --with-apr[-util] parameters, either. What about an ebuild that makes an apr-0.9.5 library from the apache-2.0.50 tarball? Then we could have a full apr and apr-util without rushing to apr-1.0.0?
I don't know which package is responsible, but neither apache or subversion depends on apr. Actually subversion blocks on apr as it should. apr-config and apu-config are both provided by apache2. Please try to remerge apache-2. If it still does not work, could you post the output of: find /var/db/pkg/ -name "*DEPEND*" -exec grep -H apr {} \;
This is fixed in subversion-1.1.0-RC4 Upstream The APR Dependency Issues are fixed in our Apache Overlay: http://svn.northnitch.com/gentoo/apache-overlay/
We are working to separating apr/apu out of both apache2 and subversion. In the mean time you could try by yourself
