On Wednesday 07 Jul 2010, Edward Ned Harvey wrote: > > From: Jon Foster [mailto:jon.fos...@cabot.co.uk] > > > > What's the full output of ldd? > > Here's how I built it: > rm -rf /scratch/eharvey/svn > mkdir /scratch/eharvey/svn > cd /scratch/eharvey > rm -rf subversion-1.6.12 > tar xjf subversion-1.6.12.tar.bz2 > tar xjf subversion-deps-1.6.12.tar.bz2 > cd subversion-1.6.12 > vi subversion/libsvn_delta/svndiff.c zlib/deflate.c > (change compression level to 1) > export LD_FLAGS=-L/scratch/eharvey/subversion-1.6.12-libz/zlib > ./configure --prefix=/scratch/eharvey/svn > --with-zlib=/scratch/eharvey/subversion-1.6.12/zlib && make && make install > && echo "made installed ok" > which svn > /scratch/eharvey/svn/bin/svn >
I hadn't realised 1.6 is different from the previous versions that I've been working with more recently. I noticed the config.log has references to --with-system-zlib which might explain the linking to the system zlib regardless of the values passed to configure. Will play with it a bit more because there should be a way to do this or there is a bug in the configure scripts. In the meantime I can confirm if you configure and make install the zlib from the deps tarfile then you can set LD_LIBRARY_PATH prior to running svn and it will pick up the compiled version of zlib. oh, and as an aside, in the steps above you'll also need to do those steps so that the configure will pick up the zlib files (although there is still the problem of it not ultimately using them). Perhaps it is different with a staticly linked binary but I've not had a chance to test that theory. > > ldd `which svn` > libsvn_client-1.so.0 => > /scratch/eharvey/svn/lib/libsvn_client-1.so.0 (0x0000002a95557000) > libsvn_wc-1.so.0 => /scratch/eharvey/svn/lib/libsvn_wc-1.so.0 > (0x0000002a9569d000) > libsvn_ra-1.so.0 => /scratch/eharvey/svn/lib/libsvn_ra-1.so.0 > (0x0000002a957e3000) > libsvn_diff-1.so.0 => /scratch/eharvey/svn/lib/libsvn_diff-1.so.0 > (0x0000002a958ed000) > libsvn_ra_local-1.so.0 => > /scratch/eharvey/svn/lib/libsvn_ra_local-1.so.0 (0x0000002a959f8000) > libsvn_repos-1.so.0 => /scratch/eharvey/svn/lib/libsvn_repos-1.so.0 > (0x0000002a95b00000) > libsvn_fs-1.so.0 => /scratch/eharvey/svn/lib/libsvn_fs-1.so.0 > (0x0000002a95c28000) > libsvn_fs_fs-1.so.0 => /scratch/eharvey/svn/lib/libsvn_fs_fs-1.so.0 > (0x0000002a95d30000) > libsvn_fs_util-1.so.0 => > /scratch/eharvey/svn/lib/libsvn_fs_util-1.so.0 (0x0000002a95e56000) > libsvn_ra_svn-1.so.0 => > /scratch/eharvey/svn/lib/libsvn_ra_svn-1.so.0 (0x0000002a95f58000) > libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00000034a9900000) > libsvn_ra_neon-1.so.0 => > /scratch/eharvey/svn/lib/libsvn_ra_neon-1.so.0 (0x0000002a9606f000) > libsvn_ra_serf-1.so.0 => > /scratch/eharvey/svn/lib/libsvn_ra_serf-1.so.0 (0x0000002a961ad000) > libserf-0.so.0 => /scratch/eharvey/svn/lib/libserf-0.so.0 > (0x0000002a962cf000) > libm.so.6 => /lib64/tls/libm.so.6 (0x00000034a6100000) > libssl.so.4 => /lib64/libssl.so.4 (0x00000034ab400000) > libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00000034aab00000) > libsvn_delta-1.so.0 => /scratch/eharvey/svn/lib/libsvn_delta-1.so.0 > (0x0000002a96408000) > libsvn_subr-1.so.0 => /scratch/eharvey/svn/lib/libsvn_subr-1.so.0 > (0x0000002a96513000) > libz.so.1 => /usr/lib64/libz.so.1 (0x00000034a6900000) > libaprutil-1.so.0 => /scratch/eharvey/svn/lib/libaprutil-1.so.0 > (0x0000002a966cb000) > libapr-1.so.0 => /scratch/eharvey/svn/lib/libapr-1.so.0 > (0x0000002a967eb000) > libuuid.so.1 => /lib64/tls/libuuid.so.1 (0x00000034a5a00000) > librt.so.1 => /lib64/tls/librt.so.1 (0x00000034a8900000) > libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000034ad100000) > libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00000034a6300000) > libdl.so.2 => /lib64/libdl.so.2 (0x00000034a5f00000) > libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 > (0x00000034aa900000) > libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00000034a9100000) > libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 > (0x00000034a9700000) libcom_err.so.2 => /lib64/libcom_err.so.2 > (0x00000034a8f00000) libresolv.so.2 => /lib64/libresolv.so.2 > (0x00000034a6d00000) libexpat.so.0 => /usr/lib64/libexpat.so.0 > (0x00000034a7700000) libc.so.6 => /lib64/tls/libc.so.6 (0x00000034a5c00000) > /lib64/ld-linux-x86-64.so.2 (0x00000034a5800000) > > > Are you linking against some other library that's linked against > > your system zlib? Run ldd on every other library that's listed, > > to see if any depend on libz.so. > > Most likely that is it. I must imagine that sasl, ssl, crypt, etc are > probably linked with the standard zlib. > > I could go on, but I bet this is a lost cause. Campbell -- __________________________________________________________________________________ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __________________________________________________________________________________
