You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Edward Ned Harvey <sv...@nedharvey.com> on 2010/07/06 14:14:23 UTC
can't build with zlib
I have tried everything I can think of, and I can't seem to get svn to build
with the zlib that comes with it. It's always linking against
/usr/lib64/zlib.
./configure --prefix=/scratch/eharvey/svn
--with-zlib=/scratch/eharvey/subversion-1.6.12/zlib --enable-static
After build:
ldd `which svn` | grep libz
libz.so.1 => /usr/lib64/libz.so.1 (0x00000034a6900000)
Perhaps I should set something like INCLUDE_PATH or LD_LIBRARY_PATH before
building it? Also, if I enable-static, shouldn't it be internal, shouldn't
ldd show me nothing?
Here's the reason why I care:
The default zlib compression is 5. I edited deflate.c to change this to 1.
I would like to know how much difference there is.
Thanks...
Re: can't build with zlib
Posted by Campbell Allan <ca...@sword-ciboodle.com>.
On Wednesday 07 Jul 2010, Edward Ned Harvey wrote:
> > From: Jon Foster [mailto:Jon.Foster@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.
__________________________________________________________________________________
RE: can't build with zlib
Posted by Edward Ned Harvey <sv...@nedharvey.com>.
> From: Jon Foster [mailto:Jon.Foster@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
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.
RE: can't build with zlib
Posted by Jon Foster <Jo...@cabot.co.uk>.
Hi,
Edward Ned Harvey wrote:
> I have tried everything I can think of, and I can't seem to get
> svn to build with the zlib that comes with it. It's always
> linking against /usr/lib64/zlib.
> After build:
> ldd `which svn` | grep libz
> libz.so.1 => /usr/lib64/libz.so.1 (0x00000034a6900000)
What's the full output of ldd?
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.
Kind regards,
Jon
--
Please direct all replies to the mailing list.
**********************************************************************
This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**********************************************************************
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
Re: can't build with zlib
Posted by Campbell Allan <ca...@sword-ciboodle.com>.
On Tuesday 06 Jul 2010, Edward Ned Harvey wrote:
> I have tried everything I can think of, and I can't seem to get svn to
> build with the zlib that comes with it. It's always linking against
> /usr/lib64/zlib.
>
>
>
> ./configure --prefix=/scratch/eharvey/svn
> --with-zlib=/scratch/eharvey/subversion-1.6.12/zlib --enable-static
>
>
Have you tried setting LD_FLAGS before running configure? I'd keep
the --with-zlib option as well. For example
LD_FLAGS=-L`pwd`/zlib
export LD_FLAGS
./configure ...
>
> After build:
>
> ldd `which svn` | grep libz
>
> libz.so.1 => /usr/lib64/libz.so.1 (0x00000034a6900000)
>
>
>
> Perhaps I should set something like INCLUDE_PATH or LD_LIBRARY_PATH before
> building it? Also, if I enable-static, shouldn't it be internal, shouldn't
> ldd show me nothing?
>
I have a vague memory that enable-static is to do with building static
libraries rathern than a static binary. ldd on a static binary should show
the message 'not a dynamic executable' or something like that. I've used a
slightly different configure line to do that. On my machine I had trouble
with the built os provided openssl so had to build my own.
./configure --prefix=/someplace --with-neon=`pwd/neon --with-ssl --disable-shared --enable-all-static --with-openssl=`pwd`/openssl
oh, and on a 64bit machine (or it might be unique to opensuse) I've found I
had to add -fPIC to the CFLAGS options before running configure.
CFLAGS=-fPIC
export CFLAGS
>
>
> Here's the reason why I care:
>
>
>
> The default zlib compression is 5. I edited deflate.c to change this to 1.
> I would like to know how much difference there is.
>
>
>
> Thanks...
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.
__________________________________________________________________________________
Re: can't build with zlib
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Edward Ned Harvey wrote on Tue, 6 Jul 2010 at 17:14 -0000:
> Also, if I enable-static, shouldn't it be internal, shouldn't ldd show
> me nothing?
Did you try --enable-all-static?
Re: can't build with zlib
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Jul 6, 2010 at 10:14 AM, Edward Ned Harvey <sv...@nedharvey.com> wrote:
> I have tried everything I can think of, and I can't seem to get svn to build
> with the zlib that comes with it. It's always linking against
> /usr/lib64/zlib.
Why do you want to? Compiling libraries internally for specific
applicatons is begging for version skew issues,and difficulties in
providing feature fixes for components: any upgrades to zlib would
force you to recompile Subversion. While local libraries are sometimes
needed because the system component is incompatible (such as some of
the historical SQLite issues on RHEL for Subversion), it's rarely
desirable.