I forgot to compose a would-be commit message for the patch. Here goes...
[[[
* build/ac-macros/apache.m4
(--with-apache-libexecdir=DIR): added this configure option. It
supplies the location of the modules of the installed httpd for
a libtool -rpath argument.
(--with-apache=DIR): this option's help string now mentions
the --with-apache-libexecdir option.
(message results): changed "Apache 2.0.x" to "Apache 2.x.x" since
I was actually using apache httpd 2.2.8.
* subversion/mod_dav_svn/static/config.m4
($enable_dav_svn): improved error message about shared linking,
fixed the library names.
($enable_authz_svn): added option --enable-authz-svn to the
apache static linking build script, to also
include mod_authz_svn.
]]]
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
> http://svn.collab.net/repos/svn/tags/0.6.0/HACKING
> 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".
>
> Solution:
>
> I included another svn configure script option called
> --with-apache-libexecdir=DIR
> 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.
>
> Reasoning:
>
> 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
> APACHE_LIBEXECDIR="/my/apache2/modules"
> , 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
> exclusive.
>
> 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.
>
> Question:
> 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
> scripts.
>
> 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
>
>
> Solution:
> The patch changes the names in the apache build scripts to the names of
> the actually installed files.
>
> Reasoning:
> That's the easiest way to fix it.
>
> Question:
> 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.
>
> Solution:
> The patch adds another option to the apache configure script called
> --enable-authz-svn
> to go along with the existing
> --enable-dav-svn
> 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.
>
> Thanks,
> Neels
>
--
Neels Janosch Hofmeyr
Software Developer
neels_at_elego.de
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 19:22:41 CET