[
https://issues.apache.org/jira/browse/SVN-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiran Chaudhuri updated SVN-4693:
---------------------------------
Description:
I am building subversion from source but always see the output files depend on
the system-supplied zlib which is way older than the one I want to use.
What I did was this:
{code:none}
./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX /apr-util
--with-sqlite=$PREFIX /sqlite
{code}
which gives me the error message that subversion requires zlib. So far so good.
Then I do
{code:none}
./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX/apr-util
--with-sqlite=$PREFIX/sqlite --with-zlib=$PREFIX/zlib
{code}
which terminates with exit code 0. The messages on stdout look ok, but when I
do make and make install, the created libraries will depend on the
system-supplied zlib instead of the one I specified to use. Further, in
config.log I can see these lines:
{code:none}
...
$ ./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX/apr-util
--with-sqlite=$PREFIX/sqlite --with-zlib=$PREFIX/zlib
...
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,a
da --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj
--disable-libmudflap --with-slibdir=/lib64 --with-system- zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program
-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=x86_64-suse-linux
...
configure:22579: zlib library configuration via prefix
configure:22585: checking zlib.h usability
configure:22585: gcc -c -g -O2 -g -O2 -pthread -DLINUX -D_REENTRANT
-D_GNU_SOURCE -I$PREFIX/zlib/include conftest.c >&5
configure:22585: $? = 0
configure:22585: result: yes
configure:22585: checking zlib.h presence
configure:22585: gcc -E -DLINUX -D_REENTRANT -D_GNU_SOURCE
-I$PREFIX/zlib/include conftest.c
configure:22585: $? = 0
configure:22585: result: yes
configure:22585: checking for zlib.h
configure:22585: result: yes
configure:22593: checking for inflate in -lz
configure:22618: gcc -o conftest -g -O2 -g -O2 -pthread -DLINUX -D_REENTRANT
-D_GNU_SOURCE -I$PREFIX/zlib/include -L$PREFIX/openldap/lib -L/a
ma/wh/bin/Apache-httpd-5451/expat/lib -L$PREFIX/zlib/lib conftest.c -lz >&5
configure:22618: $? = 0
configure:22627: result: yes
{code}
So this is confusing for me. While the parameter I passed was recognized and
the different checks on zlib were successful, the overall result is
--with-system-zlib?
After make and make install, when I check the compiled libraries I get this
output:
{code:none}
ldd libsvn_client-1.so
...
libz.so.1 => /lib64/libz.so.1 (0x00007fc978e9f000)
...
{code}
This shows me that the system zlib library is indeed referenced. How would I
compile subversion with zlib in a nonstandard location? Unfortunately the
impact is that Apache, when used with SVN, has two different dependencies upon
zlib which results in conflicts during runtime.
Note: the variable $PREFIX does not exist. Instead I work with fully qualified
path names but I wanted to save people from reading unnecessary long path
names.
was:
I am building subversion from source but always see the output files depend on
the system-supplied zlib which is way older than the one I want to use.
What I did was this:
{code:none}
./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX /apr-util
--with-sqlite=$PREFIX /sqlite
{code}
which gives me the error message that subversion requires zlib. So far so good.
Then I do
{code:none}
./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX/apr-util
--with-sqlite=$PREFIX/sqlite --with-zlib=$PREFIX/zlib
{code}
which terminates with exit code 0. The messages on stdout look ok, but when I
do make and make install, the created libraries will depend on the
system-supplied zlib instead of the one I specified to use. Further, in
config.log I can see these lines:
{code:none}
...
$ ./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX/apr-util
--with-sqlite=$PREFIX/sqlite --with-zlib=$PREFIX/zlib
...
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,a
da --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj
--disable-libmudflap --with-slibdir=/lib64 --with-system- zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program
-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=x86_64-suse-linux
...
configure:22579: zlib library configuration via prefix
configure:22585: checking zlib.h usability
configure:22585: gcc -c -g -O2 -g -O2 -pthread -DLINUX -D_REENTRANT
-D_GNU_SOURCE -I$PREFIX/zlib/include conftest.c >&5
configure:22585: $? = 0
configure:22585: result: yes
configure:22585: checking zlib.h presence
configure:22585: gcc -E -DLINUX -D_REENTRANT -D_GNU_SOURCE
-I$PREFIX/zlib/include conftest.c
configure:22585: $? = 0
configure:22585: result: yes
configure:22585: checking for zlib.h
configure:22585: result: yes
configure:22593: checking for inflate in -lz
configure:22618: gcc -o conftest -g -O2 -g -O2 -pthread -DLINUX -D_REENTRANT
-D_GNU_SOURCE -I$PREFIX/zlib/include -L$PREFIX/openldap/lib -L/a
ma/wh/bin/Apache-httpd-5451/expat/lib -L$PREFIX/zlib/lib conftest.c -lz >&5
configure:22618: $? = 0
configure:22627: result: yes
{code}
So this is confusing for me. While the parameter I passed was recognized and
the different checks on zlib were successful, the overall result is
--with-system-zlib?
After make and make install, when I check the compiled libraries I get this
output:
{code:none}
ldd libsvn_client-1.so
...
libz.so.1 => /lib64/libz.so.1 (0x00007fc978e9f000)
...
{code}
This shows me that the system zlib library is indeed referenced. How would I
compile subversion with zlib in a nonstandard location?
Note: the variable $PREFIX does not exist. Instead I work with fully qualified
path names but I wanted to save people from reading unnecessary long path
names.
> building subversion --with-zlib=.... seems to have no effect
> ------------------------------------------------------------
>
> Key: SVN-4693
> URL: https://issues.apache.org/jira/browse/SVN-4693
> Project: Subversion
> Issue Type: Bug
> Components: compile
> Affects Versions: 1.9.5
> Environment: SLES11 or RHEL6 with latest available development tools
> installed
> Reporter: Hiran Chaudhuri
> Labels: build, zlib
>
> I am building subversion from source but always see the output files depend
> on the system-supplied zlib which is way older than the one I want to use.
> What I did was this:
> {code:none}
> ./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX /apr-util
> --with-sqlite=$PREFIX /sqlite
> {code}
> which gives me the error message that subversion requires zlib. So far so
> good. Then I do
> {code:none}
> ./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX/apr-util
> --with-sqlite=$PREFIX/sqlite --with-zlib=$PREFIX/zlib
> {code}
> which terminates with exit code 0. The messages on stdout look ok, but when I
> do make and make install, the created libraries will depend on the
> system-supplied zlib instead of the one I specified to use. Further, in
> config.log I can see these lines:
> {code:none}
> ...
> $ ./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX/apr-util
> --with-sqlite=$PREFIX/sqlite --with-zlib=$PREFIX/zlib
> ...
> Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
> --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
> --enable-languages=c,c++,objc,fortran,obj-c++,java,a
> da --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
> --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
> --with-pkgversion='SUSE Linux' --disable-libgcj
> --disable-libmudflap --with-slibdir=/lib64 --with-system- zlib
> --enable-__cxa_atexit --enable-libstdcxx-allocator=new
> --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program
> -suffix=-4.3 --enable-linux-futex --without-system-libunwind
> --with-cpu=generic --build=x86_64-suse-linux
> ...
> configure:22579: zlib library configuration via prefix
> configure:22585: checking zlib.h usability
> configure:22585: gcc -c -g -O2 -g -O2 -pthread -DLINUX -D_REENTRANT
> -D_GNU_SOURCE -I$PREFIX/zlib/include conftest.c >&5
> configure:22585: $? = 0
> configure:22585: result: yes
> configure:22585: checking zlib.h presence
> configure:22585: gcc -E -DLINUX -D_REENTRANT -D_GNU_SOURCE
> -I$PREFIX/zlib/include conftest.c
> configure:22585: $? = 0
> configure:22585: result: yes
> configure:22585: checking for zlib.h
> configure:22585: result: yes
> configure:22593: checking for inflate in -lz
> configure:22618: gcc -o conftest -g -O2 -g -O2 -pthread -DLINUX -D_REENTRANT
> -D_GNU_SOURCE -I$PREFIX/zlib/include -L$PREFIX/openldap/lib -L/a
> ma/wh/bin/Apache-httpd-5451/expat/lib -L$PREFIX/zlib/lib conftest.c -lz >&5
> configure:22618: $? = 0
> configure:22627: result: yes
> {code}
> So this is confusing for me. While the parameter I passed was recognized and
> the different checks on zlib were successful, the overall result is
> --with-system-zlib?
> After make and make install, when I check the compiled libraries I get this
> output:
> {code:none}
> ldd libsvn_client-1.so
> ...
> libz.so.1 => /lib64/libz.so.1 (0x00007fc978e9f000)
> ...
> {code}
> This shows me that the system zlib library is indeed referenced. How would I
> compile subversion with zlib in a nonstandard location? Unfortunately the
> impact is that Apache, when used with SVN, has two different dependencies
> upon zlib which results in conflicts during runtime.
> Note: the variable $PREFIX does not exist. Instead I work with fully
> qualified path names but I wanted to save people from reading unnecessary
> long path names.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
