Summary: | subversion-1.1.0_rc2 with apr-1.0.0 undefined reference to APR_STATUS_IS_SUCCESS | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeff Kowalczyk <jeff.kowalczyk> |
Component: | [OLD] Unspecified | Assignee: | Paul de Vrieze (RETIRED) <pauldv> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jeff Kowalczyk
2004-09-04 12:04:51 UTC
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 |