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/04 18:51:15 UTC
Re: OT: $SVN envvars Re: svn 1.8 debugging-compilation-serf-configure
problem because of 1.6 Ubuntu install
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)
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.