just to let you know, the 1.7.5 version now builds again. but i was not able to tell what made it work again ...
On Mon, Mar 12, 2012 at 9:51 AM, Stefan Sperling <s...@elego.de> wrote: > 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.
