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.
Received on 2012-03-12 09:52:25 CET