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 <stsp_at_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.
Received on 2012-05-28 11:57:12 CEST