You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gabriela Gibson <ga...@gmail.com> on 2013/03/01 11:35:25 UTC
svn 1.8 debugging-compilation-serf-configure problem because of 1.6
Ubuntu install
I have an old 1.6 Ubuntu installed svn, and it's blocking me from
debugging because the client format is to old. Since I need a working
svn to do anything, I cannot just get rid of it.
This is what happens when I try to debug anything:
in emacs24:
M-x libtool --mode=execute gdb -i=mi --epoch
/home/g/trunk/subversion/svn/svn
cd ~/trunk
run log
but alas:
"subversion/libsvn_wc/wc_db.c:8898: (apr_err=155036)
subversion/libsvn_wc/wc_db_wcroot.c:737: (apr_err=155036)
subversion/libsvn_wc/wc_db_wcroot.c:316: (apr_err=155036)
svn: E155036: The working copy at '/home/g/trunk'
is too old (format 10) to work with client version '1.8.0-dev
(under development)' (expects format 31).
You need to upgrade the working copy first.
Process gdb-inferior killed
"
and the reason I was trying to get serf going is:
g@musashi:~/svn/log$ SVN=~/trunk/subversion/svn/svn
g@musashi:~/svn/log$ rm -rf trunk
g@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@musashi:~/svn/log$
(which I assume to be a serf problem)
To cut a very long story short: nothing works for me :)
And btw, the configure script still claims that:
--------------
configure: WARNING: unrecognized options: --enable-maintainer-mode,
--with-serf, --with-prefix
--------------
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
An appropriate version of serf could not be found, so libsvn_ra_serf
will not be built. If you want to build libsvn_ra_serf, please
install serf 1.0.0 or newer.
configure: error: Serf was explicitly enabled but an appropriate version
was not found.
-----------------
(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?
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?
many thanks for any advice,
Gabriela
Re: svn 1.8 debugging-compilation-serf-configure problem because
of 1.6 Ubuntu install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Fri, Mar 01, 2013 at 10:35:25 +0000:
> M-x libtool --mode=execute gdb -i=mi --epoch
> /home/g/trunk/subversion/svn/svn
> cd ~/trunk
> run log
> subversion/libsvn_wc/wc_db_wcroot.c:316: (apr_err=155036)
> svn: E155036: The working copy at '/home/g/trunk'
> is too old (format 10) to work with client version '1.8.0-dev
> (under development)' (expects format 31).
> You need to upgrade the working copy first.
> Process gdb-inferior killed
> "
'svn log' == 'svn log ./'. You should run the command in a 1.8-format
wc, or provide a target (maybe a URL target).
>
> 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@musashi:~/svn/log$
> (which I assume to be a serf problem)
>
The problem is likely that you didn't build libsvn_ra_serf, as
your configure output snippet shows. Check 'svn --version'
> To cut a very long story short: nothing works for me :)
>
> And btw, the configure script still claims that:
>
> --------------
> configure: WARNING: unrecognized options: --enable-maintainer-mode,
> --with-serf, --with-prefix
> --------------
>
Odd...
> 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
>
> An appropriate version of serf could not be found, so libsvn_ra_serf
> will not be built. If you want to build libsvn_ra_serf, please
> install serf 1.0.0 or newer.
>
> configure: error: Serf was explicitly enabled but an appropriate version
> was not found.
> -----------------
> (it clearly is present, get-deps.sh fetched and unzipped it)
>
What are you pointing --with-serf's argument to? I point it to the
value of --prefix in serf's build (configure and serfmake both have such
an argument) --- i.e., I build+install serf before configuring svn.
> 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?
We don't build serf as part of svn's build system.
Re: svn 1.8 debugging-compilation-serf-configure problem because of
1.6 Ubuntu install
Posted by Ben Reser <be...@reser.org>.
On Fri, Mar 1, 2013 at 10:42 AM, Philip Martin
<ph...@wandisco.com> wrote:
> I work on Debian which is similar to Ubuntu. I think Subversion's
> configure blindly passes all configure options to any in-tree apr and
> apr-util builds and apr and apr-util warn about options that only apply
> to Subversion. I don't do in-tree apr and apr-util builds so I don't
> see the warnings.
I stand corrected. And yes that makes perfect sense.
Re: svn 1.8 debugging-compilation-serf-configure problem because of 1.6 Ubuntu install
Posted by Philip Martin <ph...@wandisco.com>.
Ben Reser <be...@reser.org> writes:
>> 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.
I work on Debian which is similar to Ubuntu. I think Subversion's
configure blindly passes all configure options to any in-tree apr and
apr-util builds and apr and apr-util warn about options that only apply
to Subversion. I don't do in-tree apr and apr-util builds so I don't
see the warnings.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Gabriela Gibson <ga...@gmail.com>.
On 04/03/13 22:48, Ben Reser wrote:
> Can you provide the output of the serf sections in config.log?
./configure --enable-maintainer-mode --with-serf=/usr/local/serf
configure:5459: result: yes
configure:5491: serf library configuration via prefix
configure:5501: checking serf.h usability
configure:5501: gcc -c -g -O2 -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -pthread -D_REENTRANT
-D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/g/trunk3/apr/include
-I/home/g/trunk3/apr-util/include -I/usr/local/serf/include/serf-1
conftest.c >&5
configure:5501: $? = 0
configure:5501: result: yes
configure:5501: checking serf.h presence
configure:5501: gcc -E -D_REENTRANT -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -I/home/g/trunk3/apr/include
-I/home/g/trunk3/apr-util/include -I/usr/local/serf/include/serf-1
conftest.c
configure:5501: $? = 0
configure:5501: result: yes
configure:5501: checking for serf.h
configure:5501: result: yes
configure:5510: checking for serf_context_create in -lserf-1
configure:5535: gcc -o conftest -g -O2 -g -O2 -Wall
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread
-D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
-I/home/g/trunk3/apr/include -I/home/g/trunk3/apr-util/include
-I/usr/local/serf/include/serf-1 -L/usr/local/serf/lib conftest.c
-lserf-1 -L/home/g/trunk3/apr-util -laprutil-1 -L/home/g/trunk3/apr
-lapr-1 -lz >&5
conftest.c:28:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
conftest.c:30:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
/usr/bin/ld: cannot find -laprutil-1
/usr/bin/ld: cannot find -lapr-1
collect2: ld returned 1 exit status
configure:5535: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "subversion"
| #define PACKAGE_TARNAME "subversion"
| #define PACKAGE_VERSION "1.8.0"
| #define PACKAGE_STRING "subversion 1.8.0"
| #define PACKAGE_BUGREPORT "http://subversion.apache.org/"
| #define PACKAGE_URL ""
| #define SVN_SOVERSION 0
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SERF_H 1
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char serf_context_create ();
| int
| main ()
| {
| return serf_context_create ();
| ;
| return 0;
| }
configure:5545: result: no
configure:5604: serf library configuration via pkg-config
configure:5608: checking for serf-2 library
configure:5634: result: no
configure:5608: checking for serf-1 library
configure:5634: result: no
configure:5642: checking was serf enabled
configure:5648: result: no
configure:5658: error: Serf was explicitly enabled but an appropriate
version was not found.
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Ben Reser <be...@reser.org>.
On Mon, Mar 4, 2013 at 10:43 AM, Gabriela Gibson
<ga...@gmail.com> wrote:
> Steps to reproduce:
>
> svn co https://svn.apache.org/repos/asf/subversion/trunk trunk3
> cd trunk3
> ./get-deps.sh
> cd apr
> ./buildconf
> cd ../apr-util/
> ./buildconf
> cd ..
> ./autogen.sh
> ./configure --enable-maintainer-mode --with-serf=/usr/local/serf
>
> Error message:
>
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> configure: serf library configuration via prefix
> checking serf.h usability... yes
> checking serf.h presence... yes
> checking for serf.h... yes
> checking for serf_context_create in -lserf-1... no
> configure: serf library configuration via pkg-config
> checking for serf-2 library... no
> checking for serf-1 library... no
> checking was serf enabled... no
>
> An appropriate version of serf could not be found, so libsvn_ra_serf
> will not be built. If you want to build libsvn_ra_serf, please
> install serf 1.2.0 or newer.
>
> configure: error: Serf was explicitly enabled but an appropriate version was
> not found.
> g@musashi:~/trunk3$
I couldn't replicate this. I installed serf-1.2.0 with
--prefix=/usr/local/serf and used identical configure parameters and
got:
configure: serf library configuration via prefix
checking serf.h usability... yes
checking serf.h presence... yes
checking for serf.h... yes
checking for serf_context_create in -lserf-1... yes
checking was serf enabled... yes
Can you provide the output of the serf sections in config.log?
Your configure output from above shows configure trying to use your
prefix and not being able to when it tries to look for
serf_context_create in the library. It then goes on to try the
pkg-config method and doesn't find serf that way either.
I recall their being some sort of issues with this on Linux that I saw
a couple weeks back but I can't seem to replicate them now.
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Ben Reser <be...@reser.org>.
On Mon, Mar 4, 2013 at 10:43 AM, Gabriela Gibson
<ga...@gmail.com> wrote:
> However, here is what happens for me:
>
> Steps to reproduce:
>
> svn co https://svn.apache.org/repos/asf/subversion/trunk trunk3
> cd trunk3
> ./get-deps.sh
> cd apr
> ./buildconf
> cd ../apr-util/
> ./buildconf
> cd ..
> ./autogen.sh
> ./configure --enable-maintainer-mode --with-serf=/usr/local/serf
>
> Error message:
>
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> configure: serf library configuration via prefix
> checking serf.h usability... yes
> checking serf.h presence... yes
> checking for serf.h... yes
> checking for serf_context_create in -lserf-1... no
> configure: serf library configuration via pkg-config
> checking for serf-2 library... no
> checking for serf-1 library... no
> checking was serf enabled... no
>
> An appropriate version of serf could not be found, so libsvn_ra_serf
> will not be built. If you want to build libsvn_ra_serf, please
> install serf 1.2.0 or newer.
>
> configure: error: Serf was explicitly enabled but an appropriate version was
> not found.
> g@musashi:~/trunk3$
This is a symptom of the issue I mentioned in a previous email. There
are two ways of detecting serf:
1) The pkg-config utility. This method is used when no option is
passed or --with-serf is set to "yes". In order for this method to
work the serf .pc file must be someplace that the pkg-config utility
will look for it (usually I believe that pkg-config looks in
/usr/lib/pkgconfig or /usr/local/lib/pkgconfig however, this could
vary by configuration on individual distributions). You can add extra
directories to this by setting PKG_CONFIG_PATH environment variable.
2) By prefix directory. This method is used when you pass a prefix
path only. In this case pkg-config is not used. This method looks in
the prefix for an include/serf.h and tries to link to -lserf. The
problem with this is that these compile/link time flags are not
necessarily enough for some platforms (and sadly yes I think some
Linux distributions are one of those platforms).
In your case if you've installed serf in /usr/local/serf, I'd try
building without any --with-serf option or --with-serf=yes. Failing
that try the same build but with the following environment variable
set:
export PKG_CONFIG_PATH=/usr/local/serf/lib/pkgconfig
As I've mentioned before we should change the above behavior to try to
run pkg-config with PKG_CONFIG_PATH=$prefix/lib/pkgconfig in the case
of a prefix being passed to us first before trying to just guess at
the prefix.
I'll try to look at this later today.
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Gabriela Gibson <ga...@gmail.com>.
On 04/03/13 23:17, Daniel Shahaf wrote:
> Gabriela Gibson wrote on Mon, Mar 04, 2013 at 23:16:21 +0000:
>> On 04/03/13 22:57, Daniel Shahaf wrote:
>>> Gabriela Gibson wrote on Mon, Mar 04, 2013 at 22:33:23 +0000:
>>
>>>> What I've also found during my experiments at the weekend is that
>>>> apr-related entries in LD_FLAGS are edited while configure runs. So:
>>>>
>>>> LD_FLAGS="-L/usr/local/serf/lib -L/usr/local/apr/lib" ./configure \
>>>> --enable-maintainer-mode --with-serf=/usr/local/serf
>>>>
>>>> failed. Examining config.log showed that the failure appeared to occur
>>>> in the link test, and that the entry for "-L/usr/local/apr/lib" has been
>>>> removed.
>>>>
>>>
>>> Which link test was it? It's hard to make any comment about the
>>> situation without seeing the code and the reason it strips -L flags.
>>> (Is that our code, or something in autoconf's m4 library, that strips
>>> the -L flags?)
>> Since there is interest in the config.log:
>>
>> LD_FLAGS="-L/usr/local/apr -L/foo/bar/baz" ./configure
>
> LDFLAGS shouldn't have an underscore?
>
Oh. No wonder that it got dropped! %-)
(Thanks, good catch. I guess I made one initial typo and then
perpetuated it with M-/ -- oops!)
Re: OT: $SVN envvars Re: svn 1.8
debugging-compilation-serf-configure problem because of 1.6 Ubuntu
install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Mon, Mar 04, 2013 at 23:16:21 +0000:
> On 04/03/13 22:57, Daniel Shahaf wrote:
>> Gabriela Gibson wrote on Mon, Mar 04, 2013 at 22:33:23 +0000:
>
>>> What I've also found during my experiments at the weekend is that
>>> apr-related entries in LD_FLAGS are edited while configure runs. So:
>>>
>>> LD_FLAGS="-L/usr/local/serf/lib -L/usr/local/apr/lib" ./configure \
>>> --enable-maintainer-mode --with-serf=/usr/local/serf
>>>
>>> failed. Examining config.log showed that the failure appeared to occur
>>> in the link test, and that the entry for "-L/usr/local/apr/lib" has been
>>> removed.
>>>
>>
>> Which link test was it? It's hard to make any comment about the
>> situation without seeing the code and the reason it strips -L flags.
>> (Is that our code, or something in autoconf's m4 library, that strips
>> the -L flags?)
> Since there is interest in the config.log:
>
> LD_FLAGS="-L/usr/local/apr -L/foo/bar/baz" ./configure
LDFLAGS shouldn't have an underscore?
> --with-serf=/usr/local/serf --enable-maintainer-mode
>
> configure:5535: gcc -o conftest -g -O2 -g -O2 -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread
> -\
> D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
> -I/home/g/trunk3/apr/include -I/home/g/trunk3/apr-util/include
> -I/usr/local/s\
> erf/include/serf-1 -L/usr/local/serf/lib conftest.c -lserf-1
> -L/home/g/trunk3/apr-util -laprutil-1 -L/home/g/trunk3/apr -lapr-\
> 1 -lz >&5
> conftest.c:28:1: warning: function declaration isn't a prototype
> [-Wstrict-prototypes]
> conftest.c:30:1: warning: function declaration isn't a prototype
> [-Wstrict-prototypes]
> /usr/bin/ld: cannot find -laprutil-1
> /usr/bin/ld: cannot find -lapr-1
> collect2: ld returned 1 exit status
>
Re: OT: $SVN envvars Re: svn 1.8
debugging-compilation-serf-configure problem because of 1.6 Ubuntu
install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Mon, Mar 04, 2013 at 23:07:47 +0000:
> On 04/03/13 22:57, Daniel Shahaf wrote:
>> Gabriela Gibson wrote on Mon, Mar 04, 2013 at 22:33:23 +0000:
>>> What I've also found during my experiments at the weekend is that
>>> apr-related entries in LD_FLAGS are edited while configure runs. So:
>>>
>>> LD_FLAGS="-L/usr/local/serf/lib -L/usr/local/apr/lib" ./configure \
>>> --enable-maintainer-mode --with-serf=/usr/local/serf
>>>
>>> failed. Examining config.log showed that the failure appeared to occur
>>> in the link test, and that the entry for "-L/usr/local/apr/lib" has been
>>> removed.
>>>
>>
>> Which link test was it? It's hard to make any comment about the
>> situation without seeing the code and the reason it strips -L flags.
>> (Is that our code, or something in autoconf's m4 library, that strips
>> the -L flags?)
>
> I think there is only check for serf.h, and one check for compiling.
> The compile test has an extra "-L/usr/local/serf/lib" flag, so I've
> mentally referred to it as "the link test".
>
> I've provided the entire serf section of the config.log file in a later
> email, but the section I was referring to is:
>
>> configure:5510: checking for serf_context_create in -lserf-1
>> configure:5535: gcc -o conftest -g -O2 -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/g/trunk3/apr/include -I/home/g/trunk3/apr-util/include -I/usr/local/serf/include/serf-1 -L/usr/local/serf/lib conftest.c -lserf-1 -L/home/g/trunk3/apr-util -laprutil-1 -L/home/g/trunk3/apr -lapr-1 -lz >&5
>> conftest.c:28:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
>> conftest.c:30:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
>> /usr/bin/ld: cannot find -laprutil-1
>> /usr/bin/ld: cannot find -lapr-1
>> collect2: ld returned 1 exit status
>
Thanks.
>>> The only way I could make the serf link test pass (and also add that
>>> "-L/usr/local/apr/lib" flag) was to supply "--with-apr --with-apr-util" and
>>> that was what my patch documented.
>>>
I think that's the correct solution in your case: passing
--with-apr=$ARG allows configure to ask apr-1-config for the LDFLAGS
value (so you won't need to hardcode it in your configure invocation).
It's not really related to serf, though. As I understand it, the issue
is entirely about making configure find and use the correct libapr: that
one should preferably point configure at libapr via --with-apr=FOO, not
via setting LDFLAGS. Does that make sense?
>>
>> That's.. odd. Adding "--with-apr" (without argument) should actually be
>> a no-op, since APR is a mandatory dependency.
>>
> Ah, bad comms on my part. I've always used --with-apr=/usr/local/apr
> --with apr-util=/usr/local/apr, rather than naked arguments. I didn't
> realise that was misleading.
"--with-apr" is valid and interpreted as "--with-apr=yes". (Same for
any --with-*)
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Gabriela Gibson <ga...@gmail.com>.
On 04/03/13 22:57, Daniel Shahaf wrote:
> Gabriela Gibson wrote on Mon, Mar 04, 2013 at 22:33:23 +0000:
>> What I've also found during my experiments at the weekend is that
>> apr-related entries in LD_FLAGS are edited while configure runs. So:
>>
>> LD_FLAGS="-L/usr/local/serf/lib -L/usr/local/apr/lib" ./configure \
>> --enable-maintainer-mode --with-serf=/usr/local/serf
>>
>> failed. Examining config.log showed that the failure appeared to occur
>> in the link test, and that the entry for "-L/usr/local/apr/lib" has been
>> removed.
>>
>
> Which link test was it? It's hard to make any comment about the
> situation without seeing the code and the reason it strips -L flags.
> (Is that our code, or something in autoconf's m4 library, that strips
> the -L flags?)
Since there is interest in the config.log:
LD_FLAGS="-L/usr/local/apr -L/foo/bar/baz" ./configure
--with-serf=/usr/local/serf --enable-maintainer-mode
configure:5535: gcc -o conftest -g -O2 -g -O2 -Wall
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread
-\
D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
-I/home/g/trunk3/apr/include -I/home/g/trunk3/apr-util/include
-I/usr/local/s\
erf/include/serf-1 -L/usr/local/serf/lib conftest.c -lserf-1
-L/home/g/trunk3/apr-util -laprutil-1 -L/home/g/trunk3/apr -lapr-\
1 -lz >&5
conftest.c:28:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
conftest.c:30:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
/usr/bin/ld: cannot find -laprutil-1
/usr/bin/ld: cannot find -lapr-1
collect2: ld returned 1 exit status
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Gabriela Gibson <ga...@gmail.com>.
On 04/03/13 22:57, Daniel Shahaf wrote:
> Gabriela Gibson wrote on Mon, Mar 04, 2013 at 22:33:23 +0000:
>> What I've also found during my experiments at the weekend is that
>> apr-related entries in LD_FLAGS are edited while configure runs. So:
>>
>> LD_FLAGS="-L/usr/local/serf/lib -L/usr/local/apr/lib" ./configure \
>> --enable-maintainer-mode --with-serf=/usr/local/serf
>>
>> failed. Examining config.log showed that the failure appeared to occur
>> in the link test, and that the entry for "-L/usr/local/apr/lib" has been
>> removed.
>>
>
> Which link test was it? It's hard to make any comment about the
> situation without seeing the code and the reason it strips -L flags.
> (Is that our code, or something in autoconf's m4 library, that strips
> the -L flags?)
I think there is only check for serf.h, and one check for compiling.
The compile test has an extra "-L/usr/local/serf/lib" flag, so I've
mentally referred to it as "the link test".
I've provided the entire serf section of the config.log file in a later
email, but the section I was referring to is:
> configure:5510: checking for serf_context_create in -lserf-1
> configure:5535: gcc -o conftest -g -O2 -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/g/trunk3/apr/include -I/home/g/trunk3/apr-util/include -I/usr/local/serf/include/serf-1 -L/usr/local/serf/lib conftest.c -lserf-1 -L/home/g/trunk3/apr-util -laprutil-1 -L/home/g/trunk3/apr -lapr-1 -lz >&5
> conftest.c:28:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
> conftest.c:30:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
> /usr/bin/ld: cannot find -laprutil-1
> /usr/bin/ld: cannot find -lapr-1
> collect2: ld returned 1 exit status
>> The only way I could make the serf link test pass (and also add that
>> "-L/usr/local/apr/lib" flag) was to supply "--with-apr --with-apr-util" and
>> that was what my patch documented.
>>
>
> That's.. odd. Adding "--with-apr" (without argument) should actually be
> a no-op, since APR is a mandatory dependency.
>
Ah, bad comms on my part. I've always used --with-apr=/usr/local/apr
--with apr-util=/usr/local/apr, rather than naked arguments. I didn't
realise that was misleading.
Re: OT: $SVN envvars Re: svn 1.8
debugging-compilation-serf-configure problem because of 1.6 Ubuntu
install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Mon, Mar 04, 2013 at 22:33:23 +0000:
> On 04/03/13 19:44, Daniel Shahaf wrote:
>
> > Do you use the system's apr (e.g., /usr/lib/libapr-1.so) or compile your
> > own? If the former you should install the "apr-dev" (or similar)
> > package, if the latter it appears you need to pass --with-apr to
> > serf/serfmake (or serf/configure if you use that).
>
> I guess I should tell you how my setup looks. I'm possibly repeating
> stuff from earlier emails, because I'm trying to put all the info in
> one place.
>
> Beyond this, I've been working with a trunk and the dependencies as
> downloaded by get-deps.sh - pretty much the classic minimal dev env.
> I chose to do this, because I thought one way to assist the project
> was to look through the eyes of someone coming new to Subversion dev
> as much as possible.
>
Good call. get-deps.sh is not something most devs use day-to-day, so
it's liable to bitrot.
> What I've also found during my experiments at the weekend is that
> apr-related entries in LD_FLAGS are edited while configure runs. So:
>
> LD_FLAGS="-L/usr/local/serf/lib -L/usr/local/apr/lib" ./configure \
> --enable-maintainer-mode --with-serf=/usr/local/serf
>
> failed. Examining config.log showed that the failure appeared to occur
> in the link test, and that the entry for "-L/usr/local/apr/lib" has been
> removed.
>
Which link test was it? It's hard to make any comment about the
situation without seeing the code and the reason it strips -L flags.
(Is that our code, or something in autoconf's m4 library, that strips
the -L flags?)
> The only way I could make the serf link test pass (and also add that
> "-L/usr/local/apr/lib" flag) was to supply "--with-apr --with-apr-util" and
> that was what my patch documented.
>
That's.. odd. Adding "--with-apr" (without argument) should actually be
a no-op, since APR is a mandatory dependency.
> Whether this is "undocumented behaviour", "a bug in the build system",
> "there is a need to document a requirement for apr-dev", or "my
> retarded/invalid build environment" I don't feel sufficiently
> experienced to judge. I just thought - this isn't right, so submit a
> patch.
>
Yeah, I agree something is wrong, I'm just not sure your patch is the
right approach.
> It might not be the correct fix :)
>
> Ben wrote
> > In your case if you've installed serf in /usr/local/serf, I'd try
> > building without any --with-serf option or --with-serf=yes. Failing
> > that try the same build but with the following environment variable
> > set:
> > export PKG_CONFIG_PATH=/usr/local/serf/lib/pkgconfig
>
> I'm not familiar with pkgconfig, so I need to educate myself.
>
> I tried yesterday without any option, and serf isn't tested for.
>
> I've also tried the --with-serf=yes suggestion:
> g@musashi:~/trunk3$ ./configure --with-serf=yes --enable-maintainer-mode
> This failed (as in configure warned that serf hadn't been found).
>
> I've further tried with the variable:
> export PKG_CONFIG_PATH=/usr/local/serf/lib/pkgconfig
> ./configure --with-serf=yes --enable-maintainer-mode
> and this succeeds.
>
/me learnt something new :)
Daniel
> G
>
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Ben Reser <be...@reser.org>.
On Mon, Mar 4, 2013 at 2:33 PM, Gabriela Gibson
<ga...@gmail.com> wrote:
> I tried yesterday without any option, and serf isn't tested for.
I think you're mistaken here. Serf is always tested for with the
pkg-config method since September.
> I've also tried the --with-serf=yes suggestion:
> g@musashi:~/trunk3$ ./configure --with-serf=yes --enable-maintainer-mode
> This failed (as in configure warned that serf hadn't been found).
Right, not surprised, /usr/local/serf/lib/pkgconfig is not one of the
paths that pkg-config looks in.
> I've further tried with the variable:
> export PKG_CONFIG_PATH=/usr/local/serf/lib/pkgconfig
> ./configure --with-serf=yes --enable-maintainer-mode
> and this succeeds.
I think you'll find that it'll work properly even if you remove the
--with-serf=yes here.
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Gabriela Gibson <ga...@gmail.com>.
On 04/03/13 19:44, Daniel Shahaf wrote:
> Do you use the system's apr (e.g., /usr/lib/libapr-1.so) or compile your
> own? If the former you should install the "apr-dev" (or similar)
> package, if the latter it appears you need to pass --with-apr to
> serf/serfmake (or serf/configure if you use that).
I guess I should tell you how my setup looks. I'm possibly repeating
stuff from earlier emails, because I'm trying to put all the info in
one place.
I started with an installed package of svn for Ubuntu 12.04 Desktop
on a clean operating system install:
g@musashi:~$ dpkg -l | grep subversion
ii subversion 1.6.17dfsg-3ubuntu3 Advanced version control system
Beyond this, I've been working with a trunk and the dependencies as
downloaded by get-deps.sh - pretty much the classic minimal dev env.
I chose to do this, because I thought one way to assist the project
was to look through the eyes of someone coming new to Subversion dev
as much as possible.
This weekend, in order to tackle the compilation of Serf, I did "sudo
make install" in the apr and apr-util directories, and compiled Serf
with the following commands:
## Serf compile command
./configure
make
sudo make install
OTOH, when I tried to use your suggestion with ./serfmake, I get a
failure
<quote>
g@musashi:~/trunk3/serf$ sudo ./serfmake --prefix=/usr/local/serf \
build check install
ERROR: exception:
ERROR: A configuration script was not found: apr-1-config
serfmake [cmd] [options]
Commands:
build Builds (default)
check Runs test cases
install Installs serf into PREFIX
clean Cleans
Options:
--with-apr=PATH prefix for installed APR and APR-util
(needs apr-1-config and apu-1-config;
will look in PATH)
--with-gssapi=PATH build serf with GSSAPI support
(needs krb5-config; will look in PATH/bin)
--prefix=PATH install serf into PATH (default:
/usr/local)
Quick guide:
serfmake --prefix=/usr/local/serf --with-apr=/usr/local/apr install
g@musashi:~/trunk3/serf$
</quote>
Providing --with-apr:
g@musashi:~/trunk3/serf$ sudo ./serfmake --prefix=/usr/local/serf \
--with-apr=/usr/local/apr build check install
works.
So that's the behaviour of the serf compile. Sorry for the
wordy-ness, but I'm trying to get everything into one place!
What I've also found during my experiments at the weekend is that
apr-related entries in LD_FLAGS are edited while configure runs. So:
LD_FLAGS="-L/usr/local/serf/lib -L/usr/local/apr/lib" ./configure \
--enable-maintainer-mode --with-serf=/usr/local/serf
failed. Examining config.log showed that the failure appeared to occur
in the link test, and that the entry for "-L/usr/local/apr/lib" has been
removed.
The only way I could make the serf link test pass (and also add that
"-L/usr/local/apr/lib" flag) was to supply "--with-apr --with-apr-util" and
that was what my patch documented.
Whether this is "undocumented behaviour", "a bug in the build system",
"there is a need to document a requirement for apr-dev", or "my
retarded/invalid build environment" I don't feel sufficiently
experienced to judge. I just thought - this isn't right, so submit a
patch.
It might not be the correct fix :)
Ben wrote
> In your case if you've installed serf in /usr/local/serf, I'd try
> building without any --with-serf option or --with-serf=yes. Failing
> that try the same build but with the following environment variable
> set:
> export PKG_CONFIG_PATH=/usr/local/serf/lib/pkgconfig
I'm not familiar with pkgconfig, so I need to educate myself.
I tried yesterday without any option, and serf isn't tested for.
I've also tried the --with-serf=yes suggestion:
g@musashi:~/trunk3$ ./configure --with-serf=yes --enable-maintainer-mode
This failed (as in configure warned that serf hadn't been found).
I've further tried with the variable:
export PKG_CONFIG_PATH=/usr/local/serf/lib/pkgconfig
./configure --with-serf=yes --enable-maintainer-mode
and this succeeds.
G
Re: OT: $SVN envvars Re: svn 1.8
debugging-compilation-serf-configure problem because of 1.6 Ubuntu
install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Mon, Mar 04, 2013 at 19:13:52 +0000:
> On 04/03/13 19:02, Daniel Shahaf wrote:
>> ./serfmake --prefix=/usr/local/serf build check install
>
> Sorry, I should have mentioned that properly -- serf is installed at
> this point. But I double checked, and for me, it is still broken.
>
> Btw, those instructions no longer work for the new serf, look:
>
> g@musashi:~/trunk6$ cd serf
> g@musashi:~/trunk6/serf$ ./serfmake --prefix=/usr/local/serf build check
> install
> ERROR: exception:
> ERROR: A configuration script was not found: apr-1-config
Do you use the system's apr (e.g., /usr/lib/libapr-1.so) or compile your
own? If the former you should install the "apr-dev" (or similar)
package, if the latter it appears you need to pass --with-apr to
serf/serfmake (or serf/configure if you use that).
Feel free to go through this on #svn-dev IRC if you prefer.
Daniel
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Gabriela Gibson <ga...@gmail.com>.
On 04/03/13 19:02, Daniel Shahaf wrote:
> ./serfmake --prefix=/usr/local/serf build check install
Sorry, I should have mentioned that properly -- serf is installed at
this point. But I double checked, and for me, it is still broken.
Btw, those instructions no longer work for the new serf, look:
g@musashi:~/trunk6$ cd serf
g@musashi:~/trunk6/serf$ ./serfmake --prefix=/usr/local/serf build check
install
ERROR: exception:
ERROR: A configuration script was not found: apr-1-config
serfmake [cmd] [options]
Commands:
build Builds (default)
check Runs test cases
install Installs serf into PREFIX
clean Cleans
Options:
--with-apr=PATH prefix for installed APR and APR-util
(needs apr-1-config and apu-1-config;
will look in PATH)
--with-gssapi=PATH build serf with GSSAPI support
(needs krb5-config; will look in PATH/bin)
--prefix=PATH install serf into PATH (default:
/usr/local)
Quick guide:
serfmake --prefix=/usr/local/serf --with-apr=/usr/local/apr install
Re: OT: $SVN envvars Re: svn 1.8
debugging-compilation-serf-configure problem because of 1.6 Ubuntu
install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Mon, Mar 04, 2013 at 18:43:29 +0000:
> On 04/03/13 18:09, Daniel Shahaf wrote:
>> Gabriela Gibson wrote on Mon, Mar 04, 2013 at 17:51:15 +0000:
>>> +However, to compile serf with Subversion, the following configure
>>> +flags are also required:
>>> +
>>> + --with-apr=/path/to/apr/install
>>> + --with-apr-util=/path/to/apr-util/install
>>> +
>>
>> First of all, are these options to svn's configure or to serf's
>> configure?
>>
>
> Serf requires them, but in this case, the Subversion build is meant.
>
>> In either case, I don't understand why they would be required. apr* are
>> mandatory dependencies, and the --with-apr argument should only serve to
>> tell configure where the APR installation it should use use, i.e., to
>> skip looking for apr in the standard locations (/usr, /usr/local, etc).
>> Can you explain?
>
> That would be overambitious! :) :) :) I simply thought that because serf
> needs those switches in it's own compile, I try that, and I got lucky.
>
> However, here is what happens for me:
>
> ./configure --enable-maintainer-mode --with-serf=/usr/local/serf
>
> Error message:
>
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> configure: serf library configuration via prefix
> checking serf.h usability... yes
> checking serf.h presence... yes
> checking for serf.h... yes
> checking for serf_context_create in -lserf-1... no
> configure: serf library configuration via pkg-config
> checking for serf-2 library... no
> checking for serf-1 library... no
> checking was serf enabled... no
>
> An appropriate version of serf could not be found, so libsvn_ra_serf
> will not be built. If you want to build libsvn_ra_serf, please
> install serf 1.2.0 or newer.
>
> configure: error: Serf was explicitly enabled but an appropriate version
> was not found.
Is it just that you need to build/install serf?
% cd serf
% ./serfmake --prefix=/usr/local/serf build check install
(for the 'install' part you need write permission on /usr/local/serf)
Or is there another point here that I'm missing..
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Gabriela Gibson <ga...@gmail.com>.
On 04/03/13 18:09, Daniel Shahaf wrote:
> Gabriela Gibson wrote on Mon, Mar 04, 2013 at 17:51:15 +0000:
>> +However, to compile serf with Subversion, the following configure
>> +flags are also required:
>> +
>> + --with-apr=/path/to/apr/install
>> + --with-apr-util=/path/to/apr-util/install
>> +
>
> First of all, are these options to svn's configure or to serf's
> configure?
>
Serf requires them, but in this case, the Subversion build is meant.
> In either case, I don't understand why they would be required. apr* are
> mandatory dependencies, and the --with-apr argument should only serve to
> tell configure where the APR installation it should use use, i.e., to
> skip looking for apr in the standard locations (/usr, /usr/local, etc).
> Can you explain?
That would be overambitious! :) :) :) I simply thought that because serf
needs those switches in it's own compile, I try that, and I got lucky.
However, here is what happens for me:
Steps to reproduce:
svn co https://svn.apache.org/repos/asf/subversion/trunk trunk3
cd trunk3
./get-deps.sh
cd apr
./buildconf
cd ../apr-util/
./buildconf
cd ..
./autogen.sh
./configure --enable-maintainer-mode --with-serf=/usr/local/serf
Error message:
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
configure: serf library configuration via prefix
checking serf.h usability... yes
checking serf.h presence... yes
checking for serf.h... yes
checking for serf_context_create in -lserf-1... no
configure: serf library configuration via pkg-config
checking for serf-2 library... no
checking for serf-1 library... no
checking was serf enabled... no
An appropriate version of serf could not be found, so libsvn_ra_serf
will not be built. If you want to build libsvn_ra_serf, please
install serf 1.2.0 or newer.
configure: error: Serf was explicitly enabled but an appropriate version
was not found.
g@musashi:~/trunk3$
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Ben Reser <be...@reser.org>.
On Mon, Mar 4, 2013 at 10:09 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> If configure won't enable serf unless --with-apr is given on the
> commandline (as opposed to "unless it finds a libapr to link against"),
> I would call that a configure bug.
It doesn't require the APR flags to enable serf here. I'm using:
'--with-serf=/Users/breser' '--with-swig=/Users/breser'
'--enable-maintainer-mode' '--prefix=/Users/breser/root-svn-trunk'
'--enable-shared' '--with-apxs=/usr/sbin/apxs'
Re: OT: $SVN envvars Re: svn 1.8
debugging-compilation-serf-configure problem because of 1.6 Ubuntu
install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Mon, Mar 04, 2013 at 17:51:15 +0000:
> +However, to compile serf with Subversion, the following configure
> +flags are also required:
> +
> + --with-apr=/path/to/apr/install
> + --with-apr-util=/path/to/apr-util/install
> +
First of all, are these options to svn's configure or to serf's
configure?
In either case, I don't understand why they would be required. apr* are
mandatory dependencies, and the --with-apr argument should only serve to
tell configure where the APR installation it should use use, i.e., to
skip looking for apr in the standard locations (/usr, /usr/local, etc).
Can you explain?
If configure won't enable serf unless --with-apr is given on the
commandline (as opposed to "unless it finds a libapr to link against"),
I would call that a configure bug.
Thanks,
Daniel
> For more about how ra_serf/ra_neon talk WebDAV, consult notes/webdav-protocol.
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Gabriela Gibson <ga...@gmail.com>.
On 01/03/13 22:53, Daniel Shahaf wrote:
> BTW, I do 'alias -g \$svn=\$SVN' so that the envvar is called "SVN"
> (scripts look for that) but interactively I can type '$svn' in
> lowercase.
>
> _create_aliases() {
thank you for that :)
The instructions on building serf were a little outdated, but I got it
all to work in the end.
(see attached patch and log)
OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Sat, Mar 02, 2013 at 00:33:28 +0200:
> Ben Reser wrote on Fri, Mar 01, 2013 at 10:04:45 -0800:
> > On Fri, Mar 1, 2013 at 2:35 AM, Gabriela Gibson
> > <ga...@gmail.com> wrote:
> > > g@musashi:~/svn/log$ SVN=~/trunk/subversion/svn/svn
> > > g@musashi:~/svn/log$ $SVN co
BTW, I do 'alias -g \$svn=\$SVN' so that the envvar is called "SVN"
(scripts look for that) but interactively I can type '$svn' in
lowercase.
_create_aliases() {
for i in \
svn svnadmin svndumpfilter svnlook svnrdump svnserve svnsync svnversion \
svnmucc \
;
do
alias -g \$$i=\$$i:u
done
alias -g \$svnauthz-validate=\$SVNAUTHZ_VALIDATE
}
Daniel
Re: svn 1.8 debugging-compilation-serf-configure problem because
of 1.6 Ubuntu install
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ben Reser wrote on Fri, Mar 01, 2013 at 10:04:45 -0800:
> On Fri, Mar 1, 2013 at 2:35 AM, Gabriela Gibson
> <ga...@gmail.com> wrote:
> > and the reason I was trying to get serf going is:
> >
> > g@musashi:~/svn/log$ SVN=~/trunk/subversion/svn/svn
> > g@musashi:~/svn/log$ rm -rf trunk
> > g@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@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.
Right. But I believe serf itself cannot be built without SSL support,
so lack of https support implies lack of http support too.
Re: svn 1.8 debugging-compilation-serf-configure problem because of
1.6 Ubuntu install
Posted by Ben Reser <be...@reser.org>.
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
<ga...@gmail.com> wrote:
> and the reason I was trying to get serf going is:
>
> g@musashi:~/svn/log$ SVN=~/trunk/subversion/svn/svn
> g@musashi:~/svn/log$ rm -rf trunk
> g@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@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
$prefix/lib/pkgconfig.
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.