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

Re: svn 1.8 debugging-compilation-serf-configure problem because of 1.6 Ubuntu install

From: Ben Reser <ben_at_reser.org>
Date: Fri, 1 Mar 2013 10:04:45 -0800

I'm going to ignore the gdb issues since I think Daniel responded to
that sufficiently.

On Fri, Mar 1, 2013 at 2:35 AM, Gabriela Gibson
<gabriela.gibson_at_gmail.com> wrote:
> and the reason I was trying to get serf going is:
> g_at_musashi:~/svn/log$ SVN=~/trunk/subversion/svn/svn
> g_at_musashi:~/svn/log$ rm -rf trunk
> g_at_musashi:~/svn/log$ $SVN co
> https://svn.apache.org/repos/asf/subversion/trunk
> subversion/svn/checkout-cmd.c:168: (apr_err=170000)
> subversion/libsvn_client/checkout.c:103: (apr_err=170000)
> subversion/libsvn_client/ra.c:498: (apr_err=170000)
> subversion/libsvn_client/ra.c:364: (apr_err=170000)
> subversion/libsvn_ra/ra_loader.c:467: (apr_err=170000)
> svn: E170000: Unrecognised URL scheme for
> 'https://svn.apache.org/repos/asf/subversion/trunk'
> g_at_musashi:~/svn/log$
> (which I assume to be a serf problem)

Unrecognized URL scheme in this case would imply to me that you don't
have SSL support.

> And btw, the configure script still claims that:
> --------------
> configure: WARNING: unrecognized options: --enable-maintainer-mode,
> --with-serf, --with-prefix
> --------------

It's not --with-prefix it's just --prefix, no idea why it's saying the
other options are invalid.

> And serf still isn't compiling for me:
> ./configure --enable-maintainer-mode --with-serf=/home/g/trunk/
> --with-prefix=/usr/svntest/
> (also tried /home/h/trunk/serf just to be sure)
> --------------
> configure: serf library configuration via pkg-config
> checking for serf-2 library... no
> checking for serf-1 library... no
> checking was serf enabled... no

The above appears to be you configuring without any --with-serf option
or with the value set to 'yes'. Otherwise you'd be getting something
like this:
configure:5508: serf library configuration via prefix
configure:5518: checking serf.h usability
configure:5518: result: yes
configure:5518: checking serf.h presence
configure:5518: result: yes
configure:5518: checking for serf.h
configure:5518: result: yes
configure:5527: checking for serf_context_create in -lserf-1
configure:5562: result: yes
configure:5659: checking was serf enabled
configure:5662: result: yes
(I did snip out some of the gcc and $? lines)

I do know that trying to use a prefix to a currently installed version
doesn't work very well in some cases right now because the prefix mode
we essentially guess what the proper values for compiler flags are
rather than using pkg-config. One of these days I'll get around to
making it try doing pkg-config with PKG_CONFIG_PATH set to

You may be able to work around this for the time being by doing:
export PKG_CONFIG_PATH=$prefix/lib/pkgconfig:$PKG_CONFIG_PATH
./configure --enable-maintainer-mode --with-serf=yes --prefix=$prefix

> (it clearly is present, get-deps.sh fetched and unzipped it)
> Also, I note the ./configure --help tells me that:
> --with-serf=PREFIX Serf HTTP client library (enabled by default if
> found)
> which makes me think that serf should build without me telling it to, since,
> it's present, and it I guess the problem is that it's not found?

Serf unlikely some of our older dependencies will not do in-tree
builds. You have to build and install serf yourself. get_deps.sh
will download it for you, but that's about it. There was another
thread recently where I mentioned that we need to update our
documentation to be clear about that, but I've been at ApacheCon this
week and haven't gotten around to it.

> Phillip said that he doesn't see that 'configure warning' happening for him,
> maybe it's an Ubuntu specific problem and a hint why things are not working
> out?

Philip (and quite a few of the rest of us) work on Ubuntu, so I don't think so.
Received on 2013-03-01 19:05:26 CET

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.