You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ju...@apache.org on 2010/01/21 18:13:02 UTC
svn commit: r901778 - /subversion/trunk/build.conf
Author: julianfoad
Date: Thu Jan 21 17:13:01 2010
New Revision: 901778
URL: http://svn.apache.org/viewvc?rev=901778&view=rev
Log:
Add missing library dependencies in 'build.conf', following some recent
change that made some more libsvn_client functions depend on libsvn_wc.
(The error was, "undefined reference to `svn_wc__node_is_status_deleted'".)
* build.conf
(client-test, svnmucc): Add libsvn_wc to the 'libs' line.
Modified:
subversion/trunk/build.conf
Modified: subversion/trunk/build.conf
URL: http://svn.apache.org/viewvc/subversion/trunk/build.conf?rev=901778&r1=901777&r2=901778&view=diff
==============================================================================
--- subversion/trunk/build.conf (original)
+++ subversion/trunk/build.conf Thu Jan 21 17:13:01 2010
@@ -852,7 +852,8 @@
path = subversion/tests/libsvn_client
sources = client-test.c
install = test
-libs = libsvn_test libsvn_delta libsvn_subr libsvn_ra libsvn_client apriconv apr neon
+libs = libsvn_test libsvn_delta libsvn_subr libsvn_ra libsvn_wc libsvn_client
+ apriconv apr neon
# ----------------------------------------------------------------------------
# Tests for libsvn_diff
@@ -1086,7 +1087,8 @@
path = tools/client-side/svnmucc
sources = svnmucc.c
install = tools
-libs = libsvn_client libsvn_ra libsvn_subr libsvn_delta apriconv apr neon
+libs = libsvn_client libsvn_ra libsvn_subr libsvn_delta libsvn_wc
+ apriconv apr neon
[diff]
type = exe
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Peter Samuelson <pe...@p12n.org>.
[Julian Foad]
> So it sounds like if we were to make the build system effectively
> require (or even automatically perform) a "make uninstall" before
> "make", that would solve it.
That's effectively what we did in the Debian packaging a long long time
ago (2005, for 1.2.0). My 1.6.x metadata says "Build-Conflicts:
libsvn-dev (<< 1.6)", which causes a build process to fail if you have
the old stuff installed (automated builds will just remove the old
stuff at this point, if necessary).
I agree with you that it isn't really an option in a less controlled
environment than Debian package building. But yes, I'd support at
least a big fat warning if autoconf can manage to link to, say,
-lsvn_subr-1, before the build.
Notice, btw, that the ability to link to something is different from
the ability to run a program that is linked to it. On a Linux ELF
platform, for example, there are two filenames that are important (both
are symlinks to a third file):
libsvn_foo-1.so used by the linker, _not_ used by applications later
libsvn_foo-1.so.0 used by applications later, _not_ used by the linker
Therefore (still assuming Linux ELF), if you remove libsvn_foo-1.so
from its installed location, that should prevent this problem without
breaking installed apps. Other platforms probably have similar
distinctions, though perhaps with other filenames.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 22, 2010 at 03:21:55PM +0000, Julian Foad wrote:
> So it sounds like if we were to make the build system effectively
> require (or even automatically perform) a "make uninstall" before
> "make", that would solve it. That's not a good solution in general
> because it's useful to be able to build before losing the current
> install,
That would disturb my setup at least.
Could you script around it in your setup, maybe?
> on systems where that works, but it sounds like it would fix
> the problem on systems like mine. Even a pre-make check that reported
> "WARNING: You have Subversion libraries already installed in the
> installation directory. This is known to cause incorrect linking on some
> systems." would help.
Yes, printing this warning would help.
Stefan
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
> > Any ideas how to fix the build system to not get confused by older
> > installed libraries existing at the path where it is configured to
> > install to?
>
> It's an old bug, and hard to solve on all the platforms libtool
> supports.
>
> Does Ubuntu use Debian's patch for reducing libtool dependencies? If
> so then using a pristine upstream libtool might work. There is some
> history here:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641
> and
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320698
>
> My own technique is to configure with --prefix to a non-existant
> location for my day-to-day development. When I decide to install a
> particular revision I reconfigure and rebuild with a proper prefix,
> moving the old libraries out of prefix/lib if necessary.
So it sounds like if we were to make the build system effectively
require (or even automatically perform) a "make uninstall" before
"make", that would solve it. That's not a good solution in general
because it's useful to be able to build before losing the current
install, on systems where that works, but it sounds like it would fix
the problem on systems like mine. Even a pre-make check that reported
"WARNING: You have Subversion libraries already installed in the
installation directory. This is known to cause incorrect linking on some
systems." would help.
- Julian
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@btopenworld.com> writes:
> Any ideas how to fix the build system to not get confused by older
> installed libraries existing at the path where it is configured to
> install to?
It's an old bug, and hard to solve on all the platforms libtool
supports.
Does Ubuntu use Debian's patch for reducing libtool dependencies? If
so then using a pristine upstream libtool might work. There is some
history here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641
and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320698
My own technique is to configure with --prefix to a non-existant
location for my day-to-day development. When I decide to install a
particular revision I reconfigure and rebuild with a proper prefix,
moving the old libraries out of prefix/lib if necessary.
--
Philip
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Julian Foad <ju...@btopenworld.com>.
Peter Samuelson wrote:
> [Stefan Sperling]
> > I'll do a build now with r901778 reverted to check.
>
> Note that one test is not conclusive. I mean, it could well be
> a platform-specific build issue. Even though we have two layers
> (gen_make, libtool) trying to shield us from platform-specific
> build issues.
When I build, I sometimes install to a local directory. I had done so in
this case. I reverted that change in my WC, and deleted my
locally-installed copy of that build, and re-built, and it built OK.
That means the build system was being confused by the (older) installed
libraries, and the patch to 'build.conf' was not otherwise necessary.
I've reverted r901778 in the repository, committing r902074.
Any ideas how to fix the build system to not get confused by older
installed libraries existing at the path where it is configured to
install to?
- Julian
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Peter Samuelson <pe...@p12n.org>.
[Stefan Sperling]
> I'll do a build now with r901778 reverted to check.
Note that one test is not conclusive. I mean, it could well be
a platform-specific build issue. Even though we have two layers
(gen_make, libtool) trying to shield us from platform-specific
build issues.
Peter
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jan 21, 2010 at 08:59:03PM +0100, Stefan Sperling wrote:
> I'll do a build now with r901778 reverted to check.
Builds fine here with r901778 reverted.
Stefan
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jan 21, 2010 at 07:48:55PM +0000, Julian Foad wrote:
> Stefan Sperling wrote:
> > On Thu, Jan 21, 2010 at 06:47:40PM +0000, Philip Martin wrote:
> > > I suppose it could be a variation of the "libtool linking against
> > > installed libraries" problem. Do you have an a pre-r899829 version of
> > > Subversion installed in prefix? If so do you still get the problem
> > > when you revert r901778 and move the installed libraries out of
> > > prefix?
> >
> > Seconded. Moving the existing installation prefix often helps.
> > It's the first thing I try whenever I have a linking issue.
>
> I guess what you're both saying is it was working OK for you so that
> patch I committed was redundant. I should revert it.
Ooops, no, I didn't test it yet :)
> I'll try the linking investigation tomorrow.
I'll do a build now with r901778 reverted to check.
Stefan
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Sperling wrote:
> On Thu, Jan 21, 2010 at 06:47:40PM +0000, Philip Martin wrote:
> > I suppose it could be a variation of the "libtool linking against
> > installed libraries" problem. Do you have an a pre-r899829 version of
> > Subversion installed in prefix? If so do you still get the problem
> > when you revert r901778 and move the installed libraries out of
> > prefix?
>
> Seconded. Moving the existing installation prefix often helps.
> It's the first thing I try whenever I have a linking issue.
I guess what you're both saying is it was working OK for you so that
patch I committed was redundant. I should revert it.
I'll try the linking investigation tomorrow.
- Julian
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jan 21, 2010 at 06:47:40PM +0000, Philip Martin wrote:
> I suppose it could be a variation of the "libtool linking against
> installed libraries" problem. Do you have an a pre-r899829 version of
> Subversion installed in prefix? If so do you still get the problem
> when you revert r901778 and move the installed libraries out of
> prefix?
Seconded. Moving the existing installation prefix often helps.
It's the first thing I try whenever I have a linking issue.
Stefan
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@btopenworld.com> writes:
> Peter Samuelson wrote:
>> [julianfoad@apache.org]
>> > Add missing library dependencies in 'build.conf', following some recent
>> > change that made some more libsvn_client functions depend on libsvn_wc.
>> > (The error was, "undefined reference to `svn_wc__node_is_status_deleted'".)
>>
>> Huh. This looks like a workaround to me, not a fix. Given
>> libsvn_client already correctly declares a dependency on libsvn_wc, I
>> would think the better fix would be for either libtool or gen_make to
>> learn how to resolve these dependencies recursively. (I thought
>> libtool already did so, in fact. And indeed on many platforms, even
>> libtool should not need to, the OS linker handles it.)
>
> I assumed that adding the dependency manually was required. We don't
> have to do it very often. I agree it would be nice if some part of the
> system could figure it out, but if that requires teaching gen-make.py
> about recursive dependencies it may well not be worth the hassle.
>
> Can anyone else comment?
I suppose it could be a variation of the "libtool linking against
installed libraries" problem. Do you have an a pre-r899829 version of
Subversion installed in prefix? If so do you still get the problem
when you revert r901778 and move the installed libraries out of
prefix?
--
Philip
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Julian Foad <ju...@btopenworld.com>.
Peter Samuelson wrote:
> [julianfoad@apache.org]
> > Add missing library dependencies in 'build.conf', following some recent
> > change that made some more libsvn_client functions depend on libsvn_wc.
> > (The error was, "undefined reference to `svn_wc__node_is_status_deleted'".)
>
> Huh. This looks like a workaround to me, not a fix. Given
> libsvn_client already correctly declares a dependency on libsvn_wc, I
> would think the better fix would be for either libtool or gen_make to
> learn how to resolve these dependencies recursively. (I thought
> libtool already did so, in fact. And indeed on many platforms, even
> libtool should not need to, the OS linker handles it.)
I assumed that adding the dependency manually was required. We don't
have to do it very often. I agree it would be nice if some part of the
system could figure it out, but if that requires teaching gen-make.py
about recursive dependencies it may well not be worth the hassle.
Can anyone else comment?
- Julian
Re: svn commit: r901778 - /subversion/trunk/build.conf
Posted by Peter Samuelson <pe...@p12n.org>.
[julianfoad@apache.org]
> Add missing library dependencies in 'build.conf', following some recent
> change that made some more libsvn_client functions depend on libsvn_wc.
> (The error was, "undefined reference to `svn_wc__node_is_status_deleted'".)
Huh. This looks like a workaround to me, not a fix. Given
libsvn_client already correctly declares a dependency on libsvn_wc, I
would think the better fix would be for either libtool or gen_make to
learn how to resolve these dependencies recursively. (I thought
libtool already did so, in fact. And indeed on many platforms, even
libtool should not need to, the OS linker handles it.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/