You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "rupert.thurner" <ru...@gmail.com> on 2012/03/03 13:41:19 UTC
link error with 1.7.3
hi,
is there anything in the subversion build script(s) which enforces a
location "lib/svn", instead of only "lib" ?
opencsw solaris packages have all the libraries in /opt/csw/lib. if we
set the flags to it with:
SVNLIB = $(prefix)/lib
...
CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$
(SVNLIB)
CONFIGURE_ARGS += --disable-mod-activation
CONFIGURE_ARGS += --with-jdk=/usr/jdk/j2sdk1.4.2_02/j2se
CONFIGURE_ARGS += --enable-javahl
CONFIGURE_ARGS += --with-apr=$(bindir)/apr-1-config
CONFIGURE_ARGS += --with-apr-util=$(bindir)/apu-1-config
CONFIGURE_ARGS += --with-apxs=$(prefix)/apache2/sbin/apxs
CONFIGURE_ARGS += --with-gnome-keyring=$(prefix)
CONFIGURE_ARGS += --with-jdk=$(JAVA_HOME)
CONFIGURE_ARGS += --with-sasl=$(prefix)
CONFIGURE_ARGS += --with-serf=$(prefix)
CONFIGURE_ARGS += --with-ssl=$(prefix)
CONFIGURE_ARGS += --with-zlib=$(prefix)
cd subversion/bindings/swig/python/libsvn_swig_py ; /bin/bash /home/
rupert/mgar-sav/pkg/subversion/trunk/work/solaris10-i386/build-isa-
i386/subversion-1.7.3/libtool --mode=install /opt/csw/bin/ginstall -c
libsvn_swig_py-1.la /home/rupert/mgar-sav/pkg/subversion/trunk/work/
solaris10-i386/install-isa-i386/lib/python/opt/csw/lib/
libsvn_swig_py-1.la
libtool: install: warning: relinking `libsvn_swig_py-1.la'
libtool: install: (cd /home/rupert/mgar-sav/pkg/subversion/trunk/work/
solaris10-i386/build-isa-i386/subversion-1.7.3/subversion/bindings/
swig/python/libsvn_swig_py; /bin/bash /home/rupert/mgar-sav/pkg/
subversion/trunk/work/solaris10-i386/build-isa-i386/subversion-1.7.3/
libtool --tag CC --silent --mode=relink /opt/SUNWspro/bin/cc -xO3 -
m32 -xarch=386 -mt -D_LARGEFILE64_SOURCE -DNE_LFS -m32 -xarch=386 -L/
opt/csw/bdb48/lib -L/opt/csw/lib -L/opt/csw/lib -lintl -liconv -L/opt/
csw/bdb48/lib/. -L/opt/csw/lib -L/opt/csw/lib -rpath /opt/csw/lib -o
libsvn_swig_py-1.la swigutil_py.lo ../../../../../subversion/
libsvn_client/libsvn_client-1.la ../../../../../subversion/libsvn_wc/
libsvn_wc-1.la ../../../../../subversion/libsvn_ra/
libsvn_ra-1.la ../../../../../subversion/libsvn_delta/
libsvn_delta-1.la ../../../../../subversion/libsvn_subr/
libsvn_subr-1.la -L/opt/csw/lib -laprutil-1 -L/opt/csw/lib -lapr-1 -
lsocket -inst-prefix-dir /home/rupert/mgar-sav/pkg/subversion/trunk/
work/solaris10-i386/install-isa-i386/lib/python)
ld: fatal: library -lsvn_client-1: not found
ld: fatal: File processing errors. No output written to .libs/
libsvn_swig_py-1.so.0.0.0
libtool: install: error: relink `libsvn_swig_py-1.la' with the above
command before installing it
gmake[2]: * [install-swig-py-lib] Error 1
gmake[2]: Leaving directory `/home/rupert/mgar-sav/pkg/subversion/
trunk/work/solaris10-i386/build-isa-i386/subversion-1.7.3'
gmake[1]: * [svn-python] Error 2
gmake[1]: Leaving directory `/home/rupert/mgar-sav/pkg/subversion/
trunk'
gmake: * [merge-isa-i386] Error 2
and if we set
SVNLIB = $(prefix)/lib/svn
everything compiles. and it puts the python files in lib/svn/python,
which is a location where we do not want to have them.
rupert.
Re: svn ingores DESTDIR, was: link error with 1.7.3
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 12, 2012 at 10:20:55PM +0100, Roderich Schupp wrote:
> On Mon, Mar 12, 2012 at 16:12, Stefan Sperling <st...@elego.de> wrote:
> > It might be some dependency that rupert needs for this build and which
> > is either located in /usr/lib64 or needs a library installed there.
>
> Probably. But that is no reason to inject -L/usr/lib64 into the linker
> flags - pkg-config files should _never_ add flags referring
> to locations that are in the standard search paths, e.g.
> /usr/lib{64} for libraries of /usr/include for header files.
> But there are a lot of sloppily written pkg-config files out there...
http://wiki.debian.org/RpathIssue has some interesting notes about
incompatibilities between Redhat and Debian in this regard. It's
unlikely that Rupert is running into these since he is compiling
on Solaris. Still, conflicting conventions between systems don't
make these kinds of problems any easier to deal with :(
Luckily the problems described in the above link seem to have been
resolved in upstream libtool by now.
> > Ah, you're correct that it may not be related to rupert's problem.
> > What I meant is actually a problem with upgrades between minor versions
> > (like 1.5 to 1.6) and the error is usually different (cannot find symbol
> > 'foo'). Thanks for pointing that out.
>
> I guess the correct answer should have been:
> Subversion uses its own scheme of "versioned symbols"
> (by never changing the signature of a function foo(),
> instead adding foo1(), foo2() etc) and also being
> careful when adding to structures.
Yes, that is why Subversion is a bit of an odd case. You can always link
binaries using old 1.x APIs to newer 1.y libraries. We never rename
existing released symbols.
> > the entirely contradictory shared library versioning rules that exist
> > in Debian and OpenBSD packaging?
>
> Why single out Debian here? I can't see a difference wrt versioning
> rules in all major Linux distributions.
Debian deliberately only links direct dependencies but not indirect ones.
This allows library updates without recompiling all indirect dependencies
but can result in more than one library linked into the same executable
at runtime and it can also break builds:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641
I don't know if there are other Linux systems that use this approach.
Anyway, this thread has wandered off-topic a bit.
I wonder if this conversation is helping Rupert or if it just leaves
him scratching his forehead :)
Re: svn ingores DESTDIR, was: link error with 1.7.3
Posted by Roderich Schupp <ro...@googlemail.com>.
On Mon, Mar 12, 2012 at 16:12, Stefan Sperling <st...@elego.de> wrote:
> It might be some dependency that rupert needs for this build and which
> is either located in /usr/lib64 or needs a library installed there.
Probably. But that is no reason to inject -L/usr/lib64 into the linker
flags - pkg-config files should _never_ add flags referring
to locations that are in the standard search paths, e.g.
/usr/lib{64} for libraries of /usr/include for header files.
But there are a lot of sloppily written pkg-config files out there...
> Ah, you're correct that it may not be related to rupert's problem.
> What I meant is actually a problem with upgrades between minor versions
> (like 1.5 to 1.6) and the error is usually different (cannot find symbol
> 'foo'). Thanks for pointing that out.
I guess the correct answer should have been:
Subversion uses its own scheme of "versioned symbols"
(by never changing the signature of a function foo(),
instead adding foo1(), foo2() etc) and also being
careful when adding to structures.
> the entirely contradictory shared library versioning rules that exist
> in Debian and OpenBSD packaging?
Why single out Debian here? I can't see a difference wrt versioning
rules in all major Linux distributions.
Cheers, Roderich
Re: svn ingores DESTDIR, was: link error with 1.7.3
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 12, 2012 at 07:18:36AM -0700, roderich.schupp@googlemail.com wrote:
> On Mar 12, 9:51 am, Stefan Sperling <s....@elego.de> wrote:
> > Well,is libtool is constructing a linker command that which
> > contains -L /usr/lib64 which causes the linker to pick up svn
> > libraries that are already installed there.
>
> It's most likely not libtool itself that's to blame here.
> May bet is on some misconfigured pkg-config (*.pc) file
> (or some old-style foo-config script) that leaks "-L /usr/lib64"
> into your build.
It might be some dependency that rupert needs for this build and which
is either located in /usr/lib64 or needs a library installed there.
> > You should uninstall previously installed subversion libraries
> > before the build.
>
> Not very helpful. Probably better to set up a chroot environment
> for a clean build. The cost of setting one up would probably
> outweigh the pain of having to check for "contamination"
> after every build with just a few builds.
Yes, a chroot would help too. The main point is to somehow get the
old libs out of the way so the build process cannot see them.
> > You could also try to force a shared library version number
> > increment. Both sets of libraries have number 1 so are considered
>
> That's a totally separate issue. You can't bump the so version
> for every trial build.
Ah, you're correct that it may not be related to rupert's problem.
What I meant is actually a problem with upgrades between minor versions
(like 1.5 to 1.6) and the error is usually different (cannot find symbol
'foo'). Thanks for pointing that out.
> > But every downstream packager handles this
> > differently so there is no point in us doing this.
>
> That's one of the lamest excuses I've heard in a long time.
Is that a cheeky way of saying that you have found a way to reconcile
the entirely contradictory shared library versioning rules that exist
in Debian and OpenBSD packaging? If so, I'll buy you a pangalactic
gargle blaster.
Re: svn ingores DESTDIR, was: link error with 1.7.3
Posted by "roderich.schupp@googlemail.com" <ro...@googlemail.com>.
On Mar 12, 9:51 am, Stefan Sperling <s....@elego.de> wrote:
> Well,is libtool is constructing a linker command that which
> contains -L /usr/lib64 which causes the linker to pick up svn
> libraries that are already installed there.
It's most likely not libtool itself that's to blame here.
May bet is on some misconfigured pkg-config (*.pc) file
(or some old-style foo-config script) that leaks "-L /usr/lib64"
into your build.
> You should uninstall previously installed subversion libraries
> before the build.
Not very helpful. Probably better to set up a chroot environment
for a clean build. The cost of setting one up would probably
outweigh the pain of having to check for "contamination"
after every build with just a few builds.
> You could also try to force a shared library version number
> increment. Both sets of libraries have number 1 so are considered
That's a totally separate issue. You can't bump the so version
for every trial build.
> But every downstream packager handles this
> differently so there is no point in us doing this.
That's one of the lamest excuses I've heard in a long time.
Cheers, Roderich
Re: svn ingores DESTDIR, was: link error with 1.7.3
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Mar 11, 2012 at 09:09:20PM -0700, rupert.thurner wrote:
> nikolai did a quick test run, allow me to copy his comment. what
> should we do about this "location resistence"?
>
> Configured like this :
> ./configure --prefix=/opt/svn
>
> build and tested :
>
> ldd ./subversion/bindings/swig/python/libsvn_swig_py/.libs/
> libsvn_swig_py-1.so | grep svn
> libsvn_client-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_client/.libs/libsvn_client-1.so.0 (0x00007fbd3754b000)
> libsvn_wc-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_wc/.libs/libsvn_wc-1.so.0 (0x00007fbd372bb000)
> libsvn_ra-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_ra/.libs/libsvn_ra-1.so.0 (0x00007fbd370ad000)
> libsvn_diff-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_diff/.libs/libsvn_diff-1.so.0 (0x00007fbd36e9c000)
> libsvn_ra_local-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x00007fbd36c93000)
> libsvn_repos-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_repos/.libs/libsvn_repos-1.so.0 (0x00007fbd36a65000)
> libsvn_fs-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_fs/.libs/libsvn_fs-1.so.0 (0x00007fbd3685d000)
> libsvn_fs_fs-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_fs_fs/.libs/libsvn_fs_fs-1.so.0 (0x00007fbd36632000)
> libsvn_fs_base-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_fs_base/.libs/libsvn_fs_base-1.so.0 (0x00007fbd36402000)
> libsvn_fs_util-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_fs_util/.libs/libsvn_fs_util-1.so.0 (0x00007fbd35e52000)
> libsvn_ra_svn-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_ra_svn/.libs/libsvn_ra_svn-1.so.0 (0x00007fbd35c39000)
> libsvn_ra_neon-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_ra_neon/.libs/libsvn_ra_neon-1.so.0 (0x00007fbd357f7000)
> libsvn_delta-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_delta/.libs/libsvn_delta-1.so.0 (0x00007fbd353be000)
> libsvn_subr-1.so.0 => /root/subversion-1.7.3/subversion/
> libsvn_subr/.libs/libsvn_subr-1.so.0 (0x00007fbd3515a000)
>
> Staged it , like this
> export DESTDIR=/opt/test ; gmake install
> and guess what happens :
>
> ldd /opt/test/opt/svn/lib64/libsvn_client-1.so | grep svn
> libsvn_wc-1.so.0 => /usr/lib64/libsvn_wc-1.so.0
> (0x00007ffebf27b000)
> libsvn_ra-1.so.0 => /usr/lib64/libsvn_ra-1.so.0
> (0x00007ffebf06f000)
> libsvn_ra_local-1.so.0 => /usr/lib64/libsvn_ra_local-1.so.0
> (0x00007ffebee66000)
> libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0
> (0x00007ffebec3b000)
> libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0
> (0x00007ffebea32000)
> libsvn_fs_fs-1.so.0 => /usr/lib64/libsvn_fs_fs-1.so.0
> (0x00007ffebe809000)
> libsvn_fs_base-1.so.0 => /usr/lib64/libsvn_fs_base-1.so.0
> (0x00007ffebe5d9000)
> libsvn_fs_util-1.so.0 => /usr/lib64/libsvn_fs_util-1.so.0
> (0x00007ffebe059000)
> libsvn_ra_svn-1.so.0 => /usr/lib64/libsvn_ra_svn-1.so.0
> (0x00007ffebde41000)
> libsvn_ra_neon-1.so.0 => /usr/lib64/libsvn_ra_neon-1.so.0
> (0x00007ffebda00000)
> libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0
> (0x00007ffebd5c9000)
> libsvn_diff-1.so.0 => /usr/lib64/libsvn_diff-1.so.0
> (0x00007ffebd3bd000)
> libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0
> (0x00007ffebd0fc000)
>
>
> Well, skipping -R in the linker call and using ldconfig makes life
> easy.
>
>
> So who to blaim ? libtool ? Good luck with that .
Well,is libtool is constructing a linker command that which
contains -L /usr/lib64 which causes the linker to pick up svn
libraries that are already installed there.
You should uninstall previously installed subversion libraries
before the build.
You could also try to force a shared library version number
increment. Both sets of libraries have number 1 so are considered
equal by the linker. I think I brought up the question about whether
we should do this before. But every downstream packager handles this
differently so there is no point in us doing this.
svn ingores DESTDIR, was: link error with 1.7.3
Posted by "rupert.thurner" <ru...@gmail.com>.
nikolai did a quick test run, allow me to copy his comment. what
should we do about this "location resistence"?
Configured like this :
./configure --prefix=/opt/svn
build and tested :
ldd ./subversion/bindings/swig/python/libsvn_swig_py/.libs/
libsvn_swig_py-1.so | grep svn
libsvn_client-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_client/.libs/libsvn_client-1.so.0 (0x00007fbd3754b000)
libsvn_wc-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_wc/.libs/libsvn_wc-1.so.0 (0x00007fbd372bb000)
libsvn_ra-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_ra/.libs/libsvn_ra-1.so.0 (0x00007fbd370ad000)
libsvn_diff-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_diff/.libs/libsvn_diff-1.so.0 (0x00007fbd36e9c000)
libsvn_ra_local-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x00007fbd36c93000)
libsvn_repos-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_repos/.libs/libsvn_repos-1.so.0 (0x00007fbd36a65000)
libsvn_fs-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_fs/.libs/libsvn_fs-1.so.0 (0x00007fbd3685d000)
libsvn_fs_fs-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_fs_fs/.libs/libsvn_fs_fs-1.so.0 (0x00007fbd36632000)
libsvn_fs_base-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_fs_base/.libs/libsvn_fs_base-1.so.0 (0x00007fbd36402000)
libsvn_fs_util-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_fs_util/.libs/libsvn_fs_util-1.so.0 (0x00007fbd35e52000)
libsvn_ra_svn-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_ra_svn/.libs/libsvn_ra_svn-1.so.0 (0x00007fbd35c39000)
libsvn_ra_neon-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_ra_neon/.libs/libsvn_ra_neon-1.so.0 (0x00007fbd357f7000)
libsvn_delta-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_delta/.libs/libsvn_delta-1.so.0 (0x00007fbd353be000)
libsvn_subr-1.so.0 => /root/subversion-1.7.3/subversion/
libsvn_subr/.libs/libsvn_subr-1.so.0 (0x00007fbd3515a000)
Staged it , like this
export DESTDIR=/opt/test ; gmake install
and guess what happens :
ldd /opt/test/opt/svn/lib64/libsvn_client-1.so | grep svn
libsvn_wc-1.so.0 => /usr/lib64/libsvn_wc-1.so.0
(0x00007ffebf27b000)
libsvn_ra-1.so.0 => /usr/lib64/libsvn_ra-1.so.0
(0x00007ffebf06f000)
libsvn_ra_local-1.so.0 => /usr/lib64/libsvn_ra_local-1.so.0
(0x00007ffebee66000)
libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0
(0x00007ffebec3b000)
libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0
(0x00007ffebea32000)
libsvn_fs_fs-1.so.0 => /usr/lib64/libsvn_fs_fs-1.so.0
(0x00007ffebe809000)
libsvn_fs_base-1.so.0 => /usr/lib64/libsvn_fs_base-1.so.0
(0x00007ffebe5d9000)
libsvn_fs_util-1.so.0 => /usr/lib64/libsvn_fs_util-1.so.0
(0x00007ffebe059000)
libsvn_ra_svn-1.so.0 => /usr/lib64/libsvn_ra_svn-1.so.0
(0x00007ffebde41000)
libsvn_ra_neon-1.so.0 => /usr/lib64/libsvn_ra_neon-1.so.0
(0x00007ffebda00000)
libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0
(0x00007ffebd5c9000)
libsvn_diff-1.so.0 => /usr/lib64/libsvn_diff-1.so.0
(0x00007ffebd3bd000)
libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0
(0x00007ffebd0fc000)
Well, skipping -R in the linker call and using ldconfig makes life
easy.
So who to blaim ? libtool ? Good luck with that .
On Mar 3, 1:41 pm, "rupert.thurner" <ru...@gmail.com> wrote:
> hi,
>
> is there anything in the subversion build script(s) which enforces a
> location "lib/svn", instead of only "lib" ?
>
> opencsw solaris packages have all the libraries in /opt/csw/lib. if we
> set the flags to it with:
> SVNLIB = $(prefix)/lib
> ...
> CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$
> (SVNLIB)
> CONFIGURE_ARGS += --disable-mod-activation
> CONFIGURE_ARGS += --with-jdk=/usr/jdk/j2sdk1.4.2_02/j2se
> CONFIGURE_ARGS += --enable-javahl
> CONFIGURE_ARGS += --with-apr=$(bindir)/apr-1-config
> CONFIGURE_ARGS += --with-apr-util=$(bindir)/apu-1-config
> CONFIGURE_ARGS += --with-apxs=$(prefix)/apache2/sbin/apxs
> CONFIGURE_ARGS += --with-gnome-keyring=$(prefix)
> CONFIGURE_ARGS += --with-jdk=$(JAVA_HOME)
> CONFIGURE_ARGS += --with-sasl=$(prefix)
> CONFIGURE_ARGS += --with-serf=$(prefix)
> CONFIGURE_ARGS += --with-ssl=$(prefix)
> CONFIGURE_ARGS += --with-zlib=$(prefix)
>
> cd subversion/bindings/swig/python/libsvn_swig_py ; /bin/bash /home/rupert/mgar-sav/pkg/subversion/trunk/work/solaris10-i386/build-isa-
> i386/subversion-1.7.3/libtool --mode=install /opt/csw/bin/ginstall -c
> libsvn_swig_py-1.la /home/rupert/mgar-sav/pkg/subversion/trunk/work/
> solaris10-i386/install-isa-i386/lib/python/opt/csw/lib/
> libsvn_swig_py-1.la
> libtool: install: warning: relinking `libsvn_swig_py-1.la'
> libtool: install: (cd /home/rupert/mgar-sav/pkg/subversion/trunk/work/
> solaris10-i386/build-isa-i386/subversion-1.7.3/subversion/bindings/
> swig/python/libsvn_swig_py; /bin/bash /home/rupert/mgar-sav/pkg/
> subversion/trunk/work/solaris10-i386/build-isa-i386/subversion-1.7.3/
> libtool --tag CC --silent --mode=relink /opt/SUNWspro/bin/cc -xO3 -
> m32 -xarch=386 -mt -D_LARGEFILE64_SOURCE -DNE_LFS -m32 -xarch=386 -L/
> opt/csw/bdb48/lib -L/opt/csw/lib -L/opt/csw/lib -lintl -liconv -L/opt/
> csw/bdb48/lib/. -L/opt/csw/lib -L/opt/csw/lib -rpath /opt/csw/lib -o
> libsvn_swig_py-1.la swigutil_py.lo ../../../../../subversion/
> libsvn_client/libsvn_client-1.la ../../../../../subversion/libsvn_wc/
> libsvn_wc-1.la ../../../../../subversion/libsvn_ra/
> libsvn_ra-1.la ../../../../../subversion/libsvn_delta/
> libsvn_delta-1.la ../../../../../subversion/libsvn_subr/
> libsvn_subr-1.la -L/opt/csw/lib -laprutil-1 -L/opt/csw/lib -lapr-1 -
> lsocket -inst-prefix-dir /home/rupert/mgar-sav/pkg/subversion/trunk/
> work/solaris10-i386/install-isa-i386/lib/python)
> ld: fatal: library -lsvn_client-1: not found
> ld: fatal: File processing errors. No output written to .libs/
> libsvn_swig_py-1.so.0.0.0
> libtool: install: error: relink `libsvn_swig_py-1.la' with the above
> command before installing it
> gmake[2]: * [install-swig-py-lib] Error 1
> gmake[2]: Leaving directory `/home/rupert/mgar-sav/pkg/subversion/
> trunk/work/solaris10-i386/build-isa-i386/subversion-1.7.3'
> gmake[1]: * [svn-python] Error 2
> gmake[1]: Leaving directory `/home/rupert/mgar-sav/pkg/subversion/
> trunk'
> gmake: * [merge-isa-i386] Error 2
>
> and if we set
> SVNLIB = $(prefix)/lib/svn
>
> everything compiles. and it puts the python files in lib/svn/python,
> which is a location where we do not want to have them.
>
> rupert.