You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Eric S. Raymond" <es...@thyrsus.com> on 2012/11/21 07:50:24 UTC
Build from source continues to be broken
autogen/configure/make transcript attached. Envronment is a stock Ubuntu
system.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Build from source continues to be broken
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Ben Reser <be...@reser.org>:
> I think our final fix here is going to be to direct people to
> get-deps.sh though.
Yes, that may well be sufficient.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Build from source continues to be broken
Posted by Ben Reser <be...@reser.org>.
On Wed, Nov 21, 2012 at 11:15 AM, Eric S. Raymond <es...@thyrsus.com> wrote:
> Yes, the build ran to completion this time. Now I can do the
> interesting work, which I've been quiet about because I don't want to
> make any promises I can't keep.
Look forward to seeing whatever you're up to.
> Actually I was trying very hard not to make any decisions at all, just
> follow the least-effort path laid out by the instructions. My error
> seems to have been running autogen.sh without reading INSTALL and
> get-deps.sh first. Perhaps autogen.sh should suggest this?
That doesn't seem unreasonable to me.
> Alas, no. I couldn't use the sqlite binary on my system because it's
> too old - 3.7.9.
Ahh yeah, I suppose sqlite is the one exception. I do usually use the
amalgamation for that.
> I understand this full well, which is why I think deprecating the
> in-tree build is probably a mistake. Keeping one set of source
> dependencies properly tracked is a lot easier than managing
> what is in effect a quirk database for an unbounded number
> of distro and packaging combinations.
As I mentioned before though, the in-tree dependencies are probably
not ideal for most people.
I think our final fix here is going to be to direct people to
get-deps.sh though.
Re: Build from source continues to be broken
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Ben Reser <be...@reser.org>:
> Our directions are mostly fine though a tad out of date since 1.3.x is
> somewhat old. I've updated them to point to apr 1.4.x and apr-util
> 1.5.x the current release branches for those projects. I've also
> tried to make it clear that you should run buildconf in the directory.
>
> Using APR 1.4.x and APR-UTIL 1.5.x worked fine for me just now. So
> you should be good now.
Yes, the build ran to completion this time. Now I can do the
interesting work, which I've been quiet about because I don't want to
make any promises I can't keep.
> However, I really don't understand the decisions you're making.
> You're choosing the least desirable options here.
Actually I was trying very hard not to make any decisions at all, just
follow the least-effort path laid out by the instructions. My error
seems to have been running autogen.sh without reading INSTALL and
get-deps.sh first. Perhaps autogen.sh should suggest this?
> Unless you have a specific need you ought to be fine just installing
> the packages provided by your distribution.
Alas, no. I couldn't use the sqlite binary on my system because it's
too old - 3.7.9.
> Unfortunately, given the large number of
> distributions and variations on package naming it's difficult to
> provide good instructions for the packages to install.
I understand this full well, which is why I think deprecating the
in-tree build is probably a mistake. Keeping one set of source
dependencies properly tracked is a lot easier than managing
what is in effect a quirk database for an unbounded number
of distro and packaging combinations.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Build from source continues to be broken
Posted by Ben Reser <be...@reser.org>.
On Wed, Nov 21, 2012 at 7:37 AM, Eric S. Raymond <es...@thyrsus.com> wrote:
> I have whatever I get from the wget recommended in the instructions printed
> by configure.
configure doesn't tell you to wget APR and APR-UTIL it tells you to do
a svn checkout. So it does appear that you have a dev checkout from
the 1.3.x branches of those two, which is one of the suggestions that
configure makes.
The problem here is that APR's 1.3.x branch seems to be broken. Just
doing a checkout of 1.3.x, buildconf, configure, make fails the same
way.
> I don't have any particular desire to do either of these things. What I want
> is for the build instructions to be clear about what I have to do, and for the
> build to succeed when I do it. Right now neither of those things is the case.
Our directions are mostly fine though a tad out of date since 1.3.x is
somewhat old. I've updated them to point to apr 1.4.x and apr-util
1.5.x the current release branches for those projects. I've also
tried to make it clear that you should run buildconf in the directory.
Using APR 1.4.x and APR-UTIL 1.5.x worked fine for me just now. So
you should be good now.
> Best would be if the configure script knew how to install these
> components correctly and just did it, bothering me only when it
> detects a failure.
That's what get-deps.sh is for, which is mentioned in our INSTALL.
However, I really don't understand the decisions you're making.
You're choosing the least desirable options here.
Using an in-tree build of APR et al is largely a legacy option in our
build system for back when we used to provide a deps source package
since the dependencies were somewhat exotic. Things have changed a
lot and the dependencies are generally packaged by all the major
distributions/operating systems out there.
While I realize your current build isn't including httpd module
support. If you ever want httpd modules, using an in-tree APR build is
going to make things harder. You really don't want to build svn and
httpd with different versions of APR (it may work but you may also run
into very subtle things that don't work depending on which versions
are built where, which I'm not going to get into here).
Unless you have a specific need you ought to be fine just installing
the packages provided by your distribution. Granted, distributions
sometimes break things, I recently worked around a very poor choice
Debian (and by extension Ubuntu) made on their APR-UTIL package that
broke our detection of bdb. Unfortunately, given the large number of
distributions and variations on package naming it's difficult to
provide good instructions for the packages to install.
HTH
Re: Build from source continues to be broken
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Julian Foad <ju...@btopenworld.com>:
> Eric S. Raymond wrote:
>
> > autogen/configure/make transcript attached. Envronment is a stock Ubuntu
> > system.
>
> I tried to reproduce this, and succeeded. I'm on Ubuntu 11.10; you?
12.10
> It's failing on
> the APR build; what version of APR source do you have here? I guess a dev snapshot from the '1.3.x' branch, since your 'configure' reports the APR and APR-UTIL versions as 1.3.13, which are not released versions.
I have whatever I get from the wget recommended in the instructions printed
by configure.
> So that makes me want to go
>
> (cd apr/ && ./buildconf && ./configure)
>
> whereupon APR configures itself with its own copy of libtool, placed in path "" relative to its own root.
But this doesn't work as a recovery step. What would?
> I think the solution is, if you want to drop a source tree inside Subversion's like this, you have to use a tarball of APR (and of APR-UTIL) that is packaged with the 'configure' script already built, and not a development checkout of APR. Alternatively, to use a development checkout of APR, build and install it separately and the point Subversion at the installed result of it.
I don't have any particular desire to do either of these things. What I want
is for the build instructions to be clear about what I have to do, and for the
build to succeed when I do it. Right now neither of those things is the case.
> Of course we (and APR) should be able to improve the diagnostics, and/or make it work.
Best would be if the configure script knew how to install these
components correctly and just did it, bothering me only when it
detects a failure.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Build from source continues to be broken
Posted by Julian Foad <ju...@btopenworld.com>.
Eric S. Raymond wrote:
> autogen/configure/make transcript attached. Envronment is a stock Ubuntu
> system.
I tried to reproduce this, and succeeded. I'm on Ubuntu 11.10; you?
The relevant error on invoking 'make' is:
[[[
$ make
------ making all in apr
/home/esr/svn/subversion/apr
make[1]: Entering directory `/home/esr/svn/subversion/apr'
make[2]: Entering directory `/home/esr/svn/subversion/apr'
/bin/bash
/libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -pthread -DHAVE_CONFIG_H
-D_REENTRANT -D_GNU_SOURCE -I./include
-I/home/esr/svn/subversion/apr/include/arch/unix -I./include/arch/unix
-I/home/esr/svn/subversion/apr/include/arch/unix
-I/home/esr/svn/subversion/apr/include -o passwd/apr_getpass.lo -c
passwd/apr_getpass.c && touch passwd/apr_getpass.lo
/bin/bash: /libtool: No such file or directory
]]]
When
I run 'make', the argument immediately after 'bash' is the absolute
path to libtool, whereas for you it just wrote '/libtool'.
It's failing on
the APR build; what version of APR source do you have here? I guess a dev snapshot from the '1.3.x' branch, since your 'configure' reports the APR and APR-UTIL versions as 1.3.13, which are not released versions.
When I export the current head of APR
[[[
$ svn export http://svn.apache.org/repos/asf/apr/apr/branches/1.3.x/ apr
[...]
$ svn export http://svn.apache.org/repos/asf/apr/apr-util/branches/1.3.x/ apr-util
[...]
$ ./autogen.sh
[...]
$ ./configure --enable-maintainer-mode --disable-shared
[...]
checking for APR... reconfig
configure: configuring package in apr now
/bin/bash: /home/julianfoad/src/subversion-esr/apr/configure: No such file or directory
configure failed for apr
]]]
So that makes me want to go
(cd apr/ && ./buildconf && ./configure)
whereupon APR configures itself with its own copy of libtool, placed in path "" relative to its own root.
I think the solution is, if you want to drop a source tree inside Subversion's like this, you have to use a tarball of APR (and of APR-UTIL) that is packaged with the 'configure' script already built, and not a development checkout of APR. Alternatively, to use a development checkout of APR, build and install it separately and the point Subversion at the installed result of it.
Of course we (and APR) should be able to improve the diagnostics, and/or make it work.
Hope that helps.
- Julian