[csw-maintainers] Fwd: Re: svn ingores DESTDIR, was: link error with 1.7.3
rupert THURNER
rupert at opencsw.org
Mon Mar 12 16:41:22 CET 2012
Fyi
---------- Forwarded message ----------
From: "Stefan Sperling" <stsp at elego.de>
Date: Mar 12, 2012 9:51 AM
Subject: Re: svn ingores DESTDIR, was: link error with 1.7.3
To: "rupert.thurner" <rupert.thurner at gmail.com>
Cc: <dev at subversion.apache.org>, <schwindt at dfki.uni-kl.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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120312/f1049595/attachment.html>
More information about the maintainers
mailing list