By now, I have verified that this patch works for:
Linux 2.6.20 (Ubuntu 7.04) i386
FreeBSD 6.2-p3 i386.
Looks like no-one has been able to do a static svn DAV build for years.
Neels Janosch Hofmeyr wrote:
> Hi dev,
> while trying to test our new treeconflicts code through WebDAV on an
> Ubuntu with a preinstalled older svn and no root access, I found out
> that the instructions I stumbled across about static linking of
> mod_dav_svn into apache did not work.
> (The instructions are found in some old svn hacker's guide at
> under "Compiling mod_dav_svn")
> I found issue #997, which basically describes the first problem
> encountered with a static apache build.
> I dug around for a day and came up with the following patch, which
> takes care of the following things in the following ways; in short,
> this patch enables using a subversion DAV with --disable-shared.
> Problem 1
> APACHE_LIBEXECDIR is not set when libtool is called to do its job
> on mod_dav_svn & co. This results in a missing -rpath argument, and
> libtool misleadingly says "only absolute paths allowed".
> I included another svn configure script option called
> which can be used to set the APACHE_LIBEXECDIR variable directly.
> This option is only allowed in addition to a --with-apache option,
> so it only can be used when building statically.
> Furthermore, if --with-apache is used, this option has to be
> supplied as well. The configure script will complain otherwise.
> To statically build the apache module, one uses --with-apache. But
> --with-apache is given the apache *source* directory.
> It basically has no way of knowing where apache will be installed.
> But the static build needs to know where apache will be installed,
> because the static library for the module needs to know a runpath
> (given by the APACHE_LIBEXECDIR).
> With a dynamic build, --with-apxs=/my/apache2/bin/apxs sets up the
> variable like this:
> APACHE_LIBEXECDIR=`/my/apache2/bin/apxs -q libexecdir`
> which will basically result in
> , being the place where the installed apache keeps its modules.
> But I do not want to use --with-apxs for a static build, because
> a) --with-apxs can be seen as implying a dynamic build;
> assuming that an apache already exists could be understood as not
> wanting to compile apache anymore. That, I guess, is why currently
> the --with-apxs and --with-apache options are setup to be mutually
> b) Also, when I already know where my apache modules will be, I do not
> want to have to install apache first to pass svn's configure script an
> apxs script location, so that configure can query the path from it.
> I just want to supply the path directly. If I want to use apxs, I can
> still install apache first, run `apxs -q libexecdir' and manually pass
> the obtained value to --with-apache-libexecdir.
> That's why I think forcing the developer to pass the APACHE_LIBEXECDIR
> in another configure option is the best solution.
> Should configure also accept an APACHE_LIBEXECDIR environment variable
> set in the shell?
> Problem 2
> The names of the static library files that make up the static
> mod_dav_svn are different from those inserted in the apache build
> Real names Names inserted in the scripts
> mod_dav_svn.la libmod_dav_svn.la
> libsvn_fs-1.la libsvn_fs.la
> libsvn_subr-1.la libsvn_subr.la
> libsvn_repos-1.la libsvn_repos.la
> libsvn_delta-1.la libsvn_delta.la
> The patch changes the names in the apache build scripts to the names of
> the actually installed files.
> That's the easiest way to fix it.
> Should this rather be implemented
> - by changing the filenames of the files that subversion installs to
> be the ones currently inserted in the apache build scripts?
> - by adding symbolic links from the script names to the real names?
> Problem 3
> To use AuthzSVNAccessFile in a svn DAV, the module mod_authz_svn.la is
> also needed, which is already being put in the apache source tree
> by subversion, but not being linked by apache.
> The patch adds another option to the apache configure script called
> to go along with the existing
> which adds mod_authz_svn.la to the apache linking.
> When supplying the old --enable-dav-svn as usual, the new
> --enable-authz-svn is enabled as well.
> The developer can manually pass "--enable-dav-svn --disable-authz-svn".
> The patch also adds a warning message to the apache configure, for the
> case that the developer fails to pass --enable-dav-svn; Since she went
> at great lengths to setup a static apache link, it seems silly to not
> enable those modules that should be linked statically.
> Btw: This warning message and the additional modules are inserted into
> the apache source tree only when requesting a static apache build. This
> patch changes the m4 script that subversion inserts into the apache
> sources, not the apache source tree itself.
> My biggest unknown with this patch is whether the static build is only
> broken on Linux (as stated by issue #997). Having all the other problems
> made me assume that no-one has made a static apache build since 2002,
> but this patch still has to be verified to work on other platforms.
> However, it fixes all static building problems on Ubuntu feisty i386.
> Find attached both the patch itself and a Makefile I cooked up to
> collect all the commands I use for statically linking my subversion with
> my apache.
> This is my first patch, so feel free to criticize my style and point out
> any other places where I should put this information. Should I post a
> comment to issue #997? Should we add an entry to the actual subversion
> hacker's guide at http://subversion.tigris.org/hacking.html about static
> apache linking?
> For a complete static userland setup to run the subversion tests through
> an apache WebDAV, I'd have some more instructions that'd be handy for
> configuring the apache. This might also be interesting for automated
> download, building and testing of subversion and apache, since it now
> works without any root access nor interference with the standard
> locations of apache and the system wide subversion libraries.
Neels Janosch Hofmeyr
Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc
elego Software Solutions GmbH http://www.elegosoft.com
Gustav-Meyer-Allee 25, Gebäude 12 HRB 77719
13355 Berlin, Germany Amtsgericht Charlottenburg
Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin
Fax: +49 30 23 45 86 95 Geschäftsführer: Olaf Wagner
Received on 2008-02-02 21:33:58 CET