On Fri, May 15, 2009 at 08:22:27PM -0400, Scott Palmer wrote:
> On 15-May-09, at 7:17 PM, Stefan Sperling wrote:
> On Fri, May 15, 2009 at 06:11:23PM -0400, Scott Palmer wrote:
> On Thu, May 14, 2009 at 8:48 AM, Stefan Sperling <stsp_at_elego.de>
> So I guess your options are:
> A 1) Use a newer APR (i.e. get it from trunk and hope it'll work)
> A 2) Install libtool 1.5 somewhere and use that to build
> A 3) Install the libapr1-dev package provided by Ubuntu instead of
> A A compiling APR yourself. There's also debug symbols in
> A A if you need them.
> A 4) Wait for new APR release and hope it'll fix this.
> Tried option 1, much better... but still fails..
> Why option 1?
> Why don't you just use the libapr1-dev package?
> Because it was first? It was natural to work through the list of options
> you gave me in order. But I didn't have time to "create a huge pile of
> work" so I stopped when #1 failed.
Sorry about that. I could have been more specific about this.
> Because I don't even know what libtool is.
That is actually a blessing :)
(I've wasted so much time already trying to fix problems caused by libtool.)
> I have no idea how I would
> acquire an older version and place it "somewhere" and manage to have it
> used by the build scripts instead of the version I already have (at least
> not without getting into an ugly mess)
OK. One thing you should keep in mind then for the future is to always
try to use things from the distribution first. Because the distribution
exists so that you don't have to do stuff like this in the first place.
It exists because others have figured this out before you, and solved
all the problems so that you can just use the software.
The only problem is that you might want to use a newer version of
some software than there is in the distro. But then, it's up to you
to do the work that the distributors usually do for you.
And even in this case, the easiest route is to try to push as much
of the work onto the distro as you can. -dev packages are your friend
when you want to compile stuff on Debian-derived distributions.
> Because the output of ./configure directed me to pull apr and apr-util
> from subversion and, that was a lot easier than guessing "libapr1-dev"
It tells you that because it is the most generic way of trying to
get things to work. If the configure script figured out the exact
operating system version you are on and list some possible options
you could take, it would be much more user-friendly. But that would
quite possibly be a nightmare to maintain for developers, because
whenever something changes in any OS, the script might become obsolete.
That's why developers usually push this kind of work onto the distributors
which provide packages for their users. The intended audience of
configure scripts are developers and admins who understand their system
> Option 4 happens by default as I try other things.
> You should try to resolve as many dependencies from your distribution
> as possible.
> Easier said than done, when you have to guess at the names of the packages
> you need.
Most of the time if a configure script complains about a missing X,
then X is contained in the name of some package, and you need to
install the corresponding -dev package (on distros derived from Debian).
Otherwise, pasting configure's complaint into a search engine and
following some of the links you get might help.
Received on 2009-05-16 14:40:30 CEST