[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Notes about getting subversion r2927 to work on FreeBSD with httpd2 head

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-09-03 01:40:22 CEST

On Sunday, September 1, 2002, at 06:37 PM, Justin Clift wrote:

> Hi Garrett,
> Me again. Just spent some time getting Subversion to build and work
> with Apache2 on a new FreeBSD 4.6.2 system.

this is something i've been meaning to work on, but it almost
certainly won't be easy to get going. it definately (as you found)
won't work out of the box. what really needs to be done is to get
the subversion port and the apache2 port to use the same apr
(preferably from the devel/apr port), which will eliminate most of
the problems. unfortunately, the various different apache2 and
suvbersion releases haven't always worked with the same versions
of apr (i'm not sure if the current versions do or not, it's been
a while since i tried it).

for now, the best way to get a subversion server working on FreeBSD
is to compile one from source by hand, as is detailed in the INSTALL
file. that said, let me try to answer some of your questions.

> Tried using your port in the standard "make install" way, but it was
> always either not working or generating things that were missing
> symbols.
> Here are some notes that we (the IRC channel guys and myself) worked
> out
> which finally ended up making it all happy.
> - The lack of libtool 1.4.x proves to be a near-killer. :-(
> - Do have a system with libtool 1.4.x already on it, and you've
> generated the dependencies with that, then tar+gzipped it up for us?
> It
> makes sense considering the limitation of libtool 1.3.x

as i said in one of my other replies to this list, i compile and
install a version of libtool 1.4.x and use it for development,
while using the system version of libtool (1.3.x) for compiling
ports. so far, this has worked ok.

> - The problem with your port is that the version of apr + apr-utils
> that
> comes with it won't work with httpd2.0.40. Well.. they compile and
> everything, but whenever you try and use either apachectl or svn it
> spits out missing symbol errors

are you saying that the version of subversion you compile from the
port doesn't work because of missing symbols? or that the version
of mod_dav that you compiled using the port didn't work because of
missing symbols? the former is a real problem, and i'd like to
know more. the latter, well, that's also a problem, but is slightly
less urgent. either way, i'd need more information on exactly what
you did and what the results were.

> - The solution was to compile and install httpd-2.0 + apr + apr-utils
> from head, then unpack the FreeBSD port version of subversion, then
> delete the apr + apr-utils that were in that, then copy the httpd2.0
> head version of them into it, then tar it up again with the same
> filename, put it in /usr/ports/distfiles, then generate a new checksum
> - Removed the "apr:${PORTSDIR}/devel/apr" line from the Makefile, as I
> wanted it to definitely use the apr stuff that I'd copied into the
> tarball from the httpd-2.0 compilation
> - Added a "--with-apxs=/path/to/apache2/bin/apxs" to the Makefile, as I
> wanted the mod_svn stuff created and automatically added to the
> httpd.conf
> - 'make' and 'make install' worked fine after this, both httpd-2.0 and
> subversion work.

as i said before, what you really should do is update the apr port
to use a version new enough to work with apache 2.0.40, and then
modify the apache2 port to use that. then (in theory) you could
have a version of the subversion port that works with the ports
tree version of apache2.

i'll be updating the apr port to the 0.9.0 release as soon as i
get the chance, but i don't know if that will work with apache
2.0.40, we might be stuck waiting for (yet another) apache release
before we can get them in sync. have i mentioned how much i'm
looking forwad to a 1.0 release of apr so we can have apache2 and
svn both using the same apr without any of these headaches?

> - Is there any way of your getting neon 23.x installed in this tree
> then
> generating the dependencies? The only reason the subversion head
> (r3111) couldn't be used is because it requires neon 23.x, but I
> couldn't add that in to the tarball as it needs libtool 1.4.x to
> generate.

i have (locally) an update to the neon port that installs a newer
version so i can use it with the HEAD of svn. actually, i have
two updates, one that updates it to work with the last release of
subversion (which isn't in the ports tree yet), which i've sent
off to roberto@freebsd.org (who usually commits this stuff for me)
along with the update to the subversion port itself, and another
to update it to a version that the current svn can use. i will
submit that back when we have a version of subversion released that
can use it (i don't want to break the version of subversion that's
in the ports tree)

honestly, updating the neon port is really easy. just change the
version numbers, update the md5, and update the library version in
pkg-plist if applicable. it's the simplest port around. if you
really want the update though, i can make it available (or just
commit it into the svn repository, along with the subversion and
apr ports).

> Anyway, thought this might be useful. My next task is to get PHP 4.2.2
> working with this setup, but I think that'll be a lot easier (am
> wishing).

well, good luck with it. i've honestly done very little with
apache2 other than setting up a bare bones subversion server, so
i can't say what kind of issues you're likely to run into.


garrett rooney                    Remember, any design flaw you're
rooneg@electricjellyfish.net      sufficiently snide about becomes
http://electricjellyfish.net/     a feature.       -- Dan Sugalski
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 3 01:40:57 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.