You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Scott Palmer <sw...@gmail.com> on 2009/05/13 01:13:02 UTC
Trouble building 1.6.x on Ubuntu 9.04
I've been trying to build 1.6.1 or 1.6.2 on Ubuntu 9.04 without success...
It's supposed to be straight-forward according to others:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2071290
But for me I get errors when doing ./configure
I've tried apr and apr-utils from the URLs that the configure script throws
out (1.2.x and from the same repo at tag 1.3.3) but they don't configure.
./buidconf seems to complain, but it typical unix fashion it's hard to tell.
Here are the bits of output that appears relevant:
...
checking whether it is safe to define __EXTENSIONS__... yes
checking for library containing strerror... none required
checking whether system uses EBCDIC... no
performing libtool configuration...
/home/scott/subversion-1.6.2/apr/configure: line 9751: syntax error near
unexpected token `lt_decl_varnames,'
/home/scott/subversion-1.6.2/apr/configure: line 9751:
`lt_if_append_uniq(lt_decl_varnames, SED, , ,'
configure failed for apr
prior to that ./buildconf in the apr folder told me:
$ ./buildconf
buildconf: checking installation...
buildconf: python version 2.6.2 (ok)
buildconf: autoconf version 2.63 (ok)
buildconf: libtool version 2.2.6 (ok)
Copying libtool helper files ...
alias: -g not found
eval: 68: Syntax error: ")" unexpected (expecting "fi")
buildconf: Using libtool.m4 at /usr/share/aclocal/libtool.m4.
Creating include/arch/unix/apr_private.h.in ...
configure.in:186: warning: LTOPTIONS_VERSION is m4_require'd but not
m4_defun'd
build/libtool.m4:67: LT_INIT is expanded from...
build/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
configure.in:186: the top level
configure.in:186: warning: LTSUGAR_VERSION is m4_require'd but not
m4_defun'd
configure.in:186: warning: LTVERSION_VERSION is m4_require'd but not
m4_defun'd
configure.in:186: warning: LTOBSOLETE_VERSION is m4_require'd but not
m4_defun'd
Creating configure ...
configure.in:186: warning: LTOPTIONS_VERSION is m4_require'd but not
m4_defun'd
build/libtool.m4:67: LT_INIT is expanded from...
build/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
configure.in:186: the top level
configure.in:186: warning: LTSUGAR_VERSION is m4_require'd but not
m4_defun'd
configure.in:186: warning: LTVERSION_VERSION is m4_require'd but not
m4_defun'd
configure.in:186: warning: LTOBSOLETE_VERSION is m4_require'd but not
m4_defun'd
configure:9753: error: possibly undefined macro: m4_ifval
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:12351: error: possibly undefined macro: _LT_SET_OPTIONS
configure:12351: error: possibly undefined macro: LT_INIT
Generating 'make' outputs ...
rebuilding rpm spec file
What's the secret to getting this puppy to build?
Thanks,
Scott
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2225257
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by we...@tigris.org.
See attached
Re: JavaHL + libtool-2 on Jaunty: unsupported hardcode properties
(was: Re: Trouble building 1.6.x on Ubuntu 9.04)
Posted by Scott Palmer <sw...@gmail.com>.
On 16-May-09, at 5:35 PM, Stefan Sperling <st...@elego.de> wrote:
> On Sat, May 16, 2009 at 05:04:02PM -0400, Scott Palmer wrote:
>> Great, but after checking Mark's link I realized I haven't compiled
>> javahl... When I try that (after installing g++) I get errors
>> from your
>> friend libtool:
>>
>> libtool: link: unsupported hardcode properties
>> libtool: link: See the libtool documentation for more information.
>> libtool: link: Fatal configuration error.
>> make: *** [subversion/bindings/javahl/native/libsvnjavahl-1.la]
>> Error 1
>> Ideas?
>
> Probably another libtool-2 related problem.
> I've changed the subject accordingly.
>
> Googling the error message indicates that a lot of people out there
> get this error trying to compile various open source projects.
>
> I don't know how to fix this. Maybe Peter Samuelson (in Cc)
> knows how to fix it, because it looks like Debian unstable has
> libtool-2 and JavaHL packages for Subversion-1.5.
> So it has to work somehow.
>
> Stefan
Well the odd thing is that none of this was mentioned at the web page
linked in Mark's message. I presume that libtool2 was used, or
perhaps they were using an earlier build of Jaunty and it had a
different libtool?
Scott
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2284591
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
JavaHL + libtool-2 on Jaunty: unsupported hardcode properties (was:
Re: Trouble building 1.6.x on Ubuntu 9.04)
Posted by Stefan Sperling <st...@elego.de>.
On Sat, May 16, 2009 at 05:04:02PM -0400, Scott Palmer wrote:
> Great, but after checking Mark's link I realized I haven't compiled
> javahl... When I try that (after installing g++) I get errors from your
> friend libtool:
>
> libtool: link: unsupported hardcode properties
> libtool: link: See the libtool documentation for more information.
> libtool: link: Fatal configuration error.
> make: *** [subversion/bindings/javahl/native/libsvnjavahl-1.la] Error 1
> Ideas?
Probably another libtool-2 related problem.
I've changed the subject accordingly.
Googling the error message indicates that a lot of people out there
get this error trying to compile various open source projects.
I don't know how to fix this. Maybe Peter Samuelson (in Cc)
knows how to fix it, because it looks like Debian unstable has
libtool-2 and JavaHL packages for Subversion-1.5.
So it has to work somehow.
Stefan
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Scott Palmer <sw...@gmail.com>.
On Sat, May 16, 2009 at 4:44 PM, Stefan Sperling <st...@elego.de> wrote:
> On Sat, May 16, 2009 at 03:54:28PM -0400, Scott Palmer wrote:
> > I'm getting better at this... the aptitude search command was the key.
>
> Great :)
>
> > Btw.. I got a few failures from make check:
>
> These aren't failures. XFAIL means that the test is expected to fail.
> They are harmless.
>
...
>
> > I'm not sure where it stands now... is the build hosed?
>
> Don't worry, the test results look fine.
Great, but after checking Mark's link I realized I haven't compiled
javahl... When I try that (after installing g++) I get errors from your
friend libtool:
libtool: link: unsupported hardcode properties
libtool: link: See the libtool documentation for more information.
libtool: link: Fatal configuration error.
make: *** [subversion/bindings/javahl/native/libsvnjavahl-1.la] Error 1
Ideas?
Scott
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2284202
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Stefan Sperling <st...@elego.de>.
On Sat, May 16, 2009 at 03:54:28PM -0400, Scott Palmer wrote:
> I'm getting better at this... the aptitude search command was the key.
Great :)
> Btw.. I got a few failures from make check:
These aren't failures. XFAIL means that the test is expected to fail.
They are harmless.
XPASS would indicate a problem -- a test expected to fail suddenly
passes for some reason.
For example, if a known bug exists that is known to be unresolved
we can add an XFAIL test for the bug. As soon as the bug has been
fixed, we can change the test to a "real" PASS/FAIL test just by
flipping a switch.
Every XFAIL test has a reason associated with its status.
If you want to find out the reason, you can search in the
subversion/tests/ directory.
> A At least one test XFAILED, checking
> /home/scott/subversion-1.6.2/tests.log
> XFAIL: lt-fs-test 18: merging commit
For example, this test from subversion/test/libsvn_fs/fs-test.c
fails because:
SVN_TEST_XFAIL(merging_commit), /* Needs to be written to match new
merge() algorithm expectations */
The reason is sometimes not given in the files themselves.
In that case, check the revision log of the file for more information.
A commit which marks a test as XFAIL should document the reason in the
log message.
> Summary of test results:
> A 24 tests SKIPPED
Skipped tests simply cannot be run on your platform or setup,
because they don't apply there. Windows-specific tests won't be run
on Linux, and if you don't have http support compiled in, http-related
tests won't be run, etc.
> A 26 tests XFAILED
>
> I'm not sure where it stands now...A is the build hosed?
Don't worry, the test results look fine.
Stefan
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Scott Palmer <sw...@gmail.com>.
On Sat, May 16, 2009 at 8:39 AM, Stefan Sperling <st...@elego.de> wrote:
> 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@elego.de
> >
> > wrote:
> >
> > 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
> > APR-1.3.3.
> >
> > A 3) Install the libapr1-dev package provided by Ubuntu
> instead of
> >
> > A A compiling APR yourself. There's also debug symbols in
> > libapr1-dbg,
> >
> > 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.
...
I'm getting better at this... the aptitude search command was the key.
Btw.. I got a few failures from make check:
At least one test XFAILED, checking /home/scott/subversion-1.6.2/tests.log
XFAIL: lt-fs-test 18: merging commit
XFAIL: lt-locks-test 9: able to reserve a name (lock non-existent path)
XFAIL: lt-locks-test 10: directory locks (kinda)
XFAIL: lt-tree-conflict-data-test 3: detect broken tree conflict data
XFAIL: basic_tests.py 38: remotely remove directories from two repositories
XFAIL: update_tests.py 50: tree conflicts 2.3: skip on 2nd update
XFAIL: switch_tests.py 10: switch a file to a dir and back to the file
XFAIL: log_tests.py 21: test log -c on range of changes
XFAIL: diff_tests.py 28: diff a renamed directory
XFAIL: diff_tests.py 49: diff URL against working copy with local mods
XFAIL: diff_tests.py 50: diff -r1 of removed file to its local addition
XFAIL: merge_tests.py 33: merge a replacement of a directory
XFAIL: merge_tests.py 34: replace both dir and one of its children
XFAIL: merge_tests.py 55: avoid repeated merges for cyclic merging
XFAIL: merge_tests.py 72: merge target with non inheritable mergeinfo
XFAIL: merge_tests.py 91: merge added subtree
XFAIL: merge_tests.py 115: tree conflicts 5.1: leaf edit, tree del
XFAIL: merge_tests.py 116: tree conflicts 5.2: leaf del, tree del
XFAIL: merge_tests.py 120: tree conflicts 5.1: leaf edit (no ci), tree del
XFAIL: merge_tests.py 121: tree conflicts 5.2: leaf del (no ci), tree del
XFAIL: merge_tests.py 125: merge prior to rename src existence still dels
src
XFAIL: revert_tests.py 4: revert a moved file
XFAIL: mergeinfo_tests.py 4: 'mergeinfo' with uninteresting source selection
XFAIL: special_tests.py 10: diff a symlink to a directory
XFAIL: info_tests.py 2: info on added file
XFAIL: tree_conflict_tests.py 14: merge dir: del/rpl/mv onto not-same
Summary of test results:
24 tests SKIPPED
26 tests XFAILED
I'm not sure where it stands now... is the build hosed?
Scott
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2283869
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Stefan Sperling <st...@elego.de>.
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 <st...@elego.de>
> wrote:
>
> 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
> APR-1.3.3.
>
> A 3) Install the libapr1-dev package provided by Ubuntu instead of
>
> A A compiling APR yourself. There's also debug symbols in
> libapr1-dbg,
>
> 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
really well.
> 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.
Stefan
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Scott Palmer <sw...@gmail.com>.
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 <st...@elego.de>
>> wrote:
>> 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
>> APR-1.3.3.
>> A 3) Install the libapr1-dev package provided by Ubuntu instead
>> of
>> A A compiling APR yourself. There's also debug symbols in
>> libapr1-dbg,
>> 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.
Because I don't even know what libtool is. 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)
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"
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.
> Anything else creates a huge pile of work.
I agree. I've found myself in the midst of that "huge pile" numerous
times.
> You're already compiling Subversion yourself. That's enough trouble
> already. Just go for option 3 unless you have a really good reason
> not to do so.
>
> Well, if you really need to build your own APR, what I'd do is:
>
> aptitude search expat
>
> and then look for packages that end in -dev. Like this one:
> libexpat1-dev - XML parsing C library - development kit
> Install that package, and APR's configure script should
> pick up expat automatically, like magic.
This is making the huge assumption that I know that "expat" is more
than just the name of a folder.
>> This happens all the time. I'm basically hitting the wall that I
>> inevitably hit when trying to get anything done on Linux -
>
> I'm basically hitting a wall whenever I'm trying to get anything done
> on anything that's neither Linux nor *BSD. It all amounts to what
> you're
> used to.
To a degree. Though it's telling that you never find complicated (and
somewhat ridiculous) ./configure scripts on Windows... Scripts that
apparently are supposed to figure all this stuff out for you, and
instead, as I have demonstrated, fail miserably. (And for the record,
in my experience, they fail often.) The need for ./configure is strong
evidence in my favour that it's *nix that is the overly complex
disaster.. and trust me I can't stand Windows, I develop on it all
day, luckily in Java so I don't go insane with win32 :-)... and I am
trying to use Linux after all ;-) My other computer is a Mac where
stuff "just works", sometimes even the unixy stuff, like ./configure,
though in this case macports was up to date so getting 1.6.2 on the
Mac was simple.
On on the Mac now, I'll try the other options in a few minutes...
thanks for the help!
Scott
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2276211
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 15, 2009 at 06:11:23PM -0400, Scott Palmer wrote:
> On Thu, May 14, 2009 at 8:48 AM, Stefan Sperling <st...@elego.de> wrote:
> 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 APR-1.3.3.
> A 3) Install the libapr1-dev package provided by Ubuntu instead of
> A A compiling APR yourself. There's also debug symbols in libapr1-dbg,
> 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?
> ...
> checking for odbc/sql.h... no
> checking Expat 1.95.x... no
> checking old Debian-packaged expat... no
> checking old FreeBSD-packaged expat... no
> checking Expat 1.0/1.1... no
> A setting LDFLAGS to "-L/usr/local/lib"
> A setting INCLUDES to "-I/usr/local/include"
> checking Expat 1.95.x in /usr/local... no
> A nulling LDFLAGS
> A nulling INCLUDES
> configuring package in xml/expat now
> /bin/bash: /home/scott/subversion-1.6.2/apr/xml/expat/configure: No such
> file or directory
> configure failed for xml/expat
> configure failed for apr
>
> Bummer.
Why don't you just use the libapr1-dev package?
You should try to resolve as many dependencies from your distribution
as possible. Anything else creates a huge pile of work.
You're already compiling Subversion yourself. That's enough trouble
already. Just go for option 3 unless you have a really good reason
not to do so.
Well, if you really need to build your own APR, what I'd do is:
aptitude search expat
and then look for packages that end in -dev. Like this one:
libexpat1-dev - XML parsing C library - development kit
Install that package, and APR's configure script should
pick up expat automatically, like magic.
> This happens all the time. I'm basically hitting the wall that I
> inevitably hit when trying to get anything done on Linux -
I'm basically hitting a wall whenever I'm trying to get anything done
on anything that's neither Linux nor *BSD. It all amounts to what you're
used to.
Stefan
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Mark Phippard <ma...@gmail.com>.
If you did not find the link, here it is:
http://blog.lv25.com/2009/04/build-subversion-16-on-ubuntu-810.html
Mark
On Fri, May 15, 2009 at 7:40 PM, Mark Phippard <ma...@gmail.com> wrote:
> Google for JavaHL Ubuntu 9.04 and there are some easy instructions. Use to
> link.
>
> Sent from my iPhone
> On May 15, 2009, at 6:11 PM, Scott Palmer <sw...@gmail.com> wrote:
>
>
>
> On Thu, May 14, 2009 at 8:48 AM, Stefan Sperling <st...@elego.de> wrote:
>>
>> On Wed, May 13, 2009 at 09:01:57PM -0400, Scott Palmer wrote:
>> > Sorry.. that was me replying via the web form...
>>
>> No worries.
>>
>> What strikes me is that you have libtool 2.2.6 on your system.
>> I have 1.5.6 on Debian stable, and I get no such errors.
>>
>> It seems like this issue has been reported to the APR developers
>> last year by Arfever (one of our developers):
>> http://marc.info/?l=apr-dev&m=120630072732498
>>
>> And it looks like the problem has been worked on recently in APR
>> by Justin and Joe (also two of our developers :)
>> http://svn.apache.org/viewvc/apr/apr/trunk/buildconf?view=log
>>
>> So I guess your options are:
>>
>> 1) Use a newer APR (i.e. get it from trunk and hope it'll work)
>> 2) Install libtool 1.5 somewhere and use that to build APR-1.3.3.
>> 3) Install the libapr1-dev package provided by Ubuntu instead of
>> compiling APR yourself. There's also debug symbols in libapr1-dbg,
>> if you need them.
>> 4) Wait for new APR release and hope it'll fix this.
>
> Tried option 1, much better... but still fails..
> ...
> checking for odbc/sql.h... no
> checking Expat 1.95.x... no
> checking old Debian-packaged expat... no
> checking old FreeBSD-packaged expat... no
> checking Expat 1.0/1.1... no
> setting LDFLAGS to "-L/usr/local/lib"
> setting INCLUDES to "-I/usr/local/include"
> checking Expat 1.95.x in /usr/local... no
> nulling LDFLAGS
> nulling INCLUDES
> configuring package in xml/expat now
> /bin/bash: /home/scott/subversion-1.6.2/apr/xml/expat/configure: No such
> file or directory
> configure failed for xml/expat
> configure failed for apr
>
> Bummer.
>
> This happens all the time. I'm basically hitting the wall that I inevitably
> hit when trying to get anything done on Linux - there are so many
> interdependencies that it's impossible to resolve them... if it isn't
> already done by the maintainers of the disto, forget it. I'm just surprised
> that Ubuntu didn't have 1.6 available to install. We're already on 1.6.2
> and they don't have 1.6.0. I'll save my rant about how ridiculous it is to
> not distribute official binaries for another day ;-)
>
> Thanks for the help, there is no way I would make any progress with out it
> (and I'm a professional developer with a degree in Computer Engineering).
>
> Scott
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2282398
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Mark Phippard <ma...@gmail.com>.
Google for JavaHL Ubuntu 9.04 and there are some easy instructions.
Use to link.
Sent from my iPhone
On May 15, 2009, at 6:11 PM, Scott Palmer <sw...@gmail.com> wrote:
>
>
> On Thu, May 14, 2009 at 8:48 AM, Stefan Sperling <st...@elego.de>
> wrote:
> On Wed, May 13, 2009 at 09:01:57PM -0400, Scott Palmer wrote:
> > Sorry.. that was me replying via the web form...
>
> No worries.
>
> What strikes me is that you have libtool 2.2.6 on your system.
> I have 1.5.6 on Debian stable, and I get no such errors.
>
> It seems like this issue has been reported to the APR developers
> last year by Arfever (one of our developers):
> http://marc.info/?l=apr-dev&m=120630072732498
>
> And it looks like the problem has been worked on recently in APR
> by Justin and Joe (also two of our developers :)
> http://svn.apache.org/viewvc/apr/apr/trunk/buildconf?view=log
>
> So I guess your options are:
>
> 1) Use a newer APR (i.e. get it from trunk and hope it'll work)
> 2) Install libtool 1.5 somewhere and use that to build APR-1.3.3.
> 3) Install the libapr1-dev package provided by Ubuntu instead of
> compiling APR yourself. There's also debug symbols in libapr1-dbg,
> if you need them.
> 4) Wait for new APR release and hope it'll fix this.
>
> Tried option 1, much better... but still fails..
> ...
> checking for odbc/sql.h... no
> checking Expat 1.95.x... no
> checking old Debian-packaged expat... no
> checking old FreeBSD-packaged expat... no
> checking Expat 1.0/1.1... no
> setting LDFLAGS to "-L/usr/local/lib"
> setting INCLUDES to "-I/usr/local/include"
> checking Expat 1.95.x in /usr/local... no
> nulling LDFLAGS
> nulling INCLUDES
> configuring package in xml/expat now
> /bin/bash: /home/scott/subversion-1.6.2/apr/xml/expat/configure: No
> such file or directory
> configure failed for xml/expat
> configure failed for apr
>
> Bummer.
>
> This happens all the time. I'm basically hitting the wall that I
> inevitably hit when trying to get anything done on Linux - there are
> so many interdependencies that it's impossible to resolve them... if
> it isn't already done by the maintainers of the disto, forget it.
> I'm just surprised that Ubuntu didn't have 1.6 available to
> install. We're already on 1.6.2 and they don't have 1.6.0. I'll
> save my rant about how ridiculous it is to not distribute official
> binaries for another day ;-)
>
> Thanks for the help, there is no way I would make any progress with
> out it (and I'm a professional developer with a degree in Computer
> Engineering).
>
> Scott
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2275826
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Scott Palmer <sw...@gmail.com>.
On Thu, May 14, 2009 at 8:48 AM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, May 13, 2009 at 09:01:57PM -0400, Scott Palmer wrote:
> > Sorry.. that was me replying via the web form...
>
> No worries.
>
> What strikes me is that you have libtool 2.2.6 on your system.
> I have 1.5.6 on Debian stable, and I get no such errors.
>
> It seems like this issue has been reported to the APR developers
> last year by Arfever (one of our developers):
> http://marc.info/?l=apr-dev&m=120630072732498
>
> And it looks like the problem has been worked on recently in APR
> by Justin and Joe (also two of our developers :)
> http://svn.apache.org/viewvc/apr/apr/trunk/buildconf?view=log
>
> So I guess your options are:
>
> 1) Use a newer APR (i.e. get it from trunk and hope it'll work)
> 2) Install libtool 1.5 somewhere and use that to build APR-1.3.3.
> 3) Install the libapr1-dev package provided by Ubuntu instead of
> compiling APR yourself. There's also debug symbols in libapr1-dbg,
> if you need them.
> 4) Wait for new APR release and hope it'll fix this.
Tried option 1, much better... but still fails..
...
checking for odbc/sql.h... no
checking Expat 1.95.x... no
checking old Debian-packaged expat... no
checking old FreeBSD-packaged expat... no
checking Expat 1.0/1.1... no
setting LDFLAGS to "-L/usr/local/lib"
setting INCLUDES to "-I/usr/local/include"
checking Expat 1.95.x in /usr/local... no
nulling LDFLAGS
nulling INCLUDES
configuring package in xml/expat now
/bin/bash: /home/scott/subversion-1.6.2/apr/xml/expat/configure: No such
file or directory
configure failed for xml/expat
configure failed for apr
Bummer.
This happens all the time. I'm basically hitting the wall that I inevitably
hit when trying to get anything done on Linux - there are so many
interdependencies that it's impossible to resolve them... if it isn't
already done by the maintainers of the disto, forget it. I'm just surprised
that Ubuntu didn't have 1.6 available to install. We're already on 1.6.2
and they don't have 1.6.0. I'll save my rant about how ridiculous it is to
not distribute official binaries for another day ;-)
Thanks for the help, there is no way I would make any progress with out it
(and I'm a professional developer with a degree in Computer Engineering).
Scott
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2275150
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Stefan Sperling <st...@elego.de>.
On Wed, May 13, 2009 at 09:01:57PM -0400, Scott Palmer wrote:
> Sorry.. that was me replying via the web form...
No worries.
What strikes me is that you have libtool 2.2.6 on your system.
I have 1.5.6 on Debian stable, and I get no such errors.
It seems like this issue has been reported to the APR developers
last year by Arfever (one of our developers):
http://marc.info/?l=apr-dev&m=120630072732498
And it looks like the problem has been worked on recently in APR
by Justin and Joe (also two of our developers :)
http://svn.apache.org/viewvc/apr/apr/trunk/buildconf?view=log
So I guess your options are:
1) Use a newer APR (i.e. get it from trunk and hope it'll work)
2) Install libtool 1.5 somewhere and use that to build APR-1.3.3.
3) Install the libapr1-dev package provided by Ubuntu instead of
compiling APR yourself. There's also debug symbols in libapr1-dbg,
if you need them.
4) Wait for new APR release and hope it'll fix this.
Stefan
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Scott Palmer <sw...@gmail.com>.
Sorry.. that was me replying via the web form...
On Wed, May 13, 2009 at 6:46 AM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, May 12, 2009 at 09:13:02PM -0400, Scott Palmer wrote:
> > prior to that ./buildconf in the apr folder told me:
> >
> > $ ./buildconf
>
> > buildconf: checking installation...
> > buildconf: python version 2.6.2 (ok)
> > buildconf: autoconf version 2.63 (ok)
> > buildconf: libtool version 2.2.6 (ok)
> > Copying libtool helper files ...
> > alias: -g not found
> > eval: 68: Syntax error: ")" unexpected (expecting "fi")
>
> That looks really, really wrong.
>
> Can you post the output of
> sh -x ./buildconf
> and
> bash -x ./buildconf
> please.
>
> Thanks,
> Stefan
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2247112
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Trouble building 1.6.x on Ubuntu 9.04
Posted by Stefan Sperling <st...@elego.de>.
On Tue, May 12, 2009 at 09:13:02PM -0400, Scott Palmer wrote:
> prior to that ./buildconf in the apr folder told me:
>
> $ ./buildconf
> buildconf: checking installation...
> buildconf: python version 2.6.2 (ok)
> buildconf: autoconf version 2.63 (ok)
> buildconf: libtool version 2.2.6 (ok)
> Copying libtool helper files ...
> alias: -g not found
> eval: 68: Syntax error: ")" unexpected (expecting "fi")
That looks really, really wrong.
Can you post the output of
sh -x ./buildconf
and
bash -x ./buildconf
please.
Thanks,
Stefan