On Wednesday 07 Jul 2010, Edward Ned Harvey wrote:
> > From: Jon Foster [mailto:Jon.Foster_at_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.
__________________________________________________________________________________
Received on 2010-07-07 18:26:52 CEST