You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Stutz Oliver <Ol...@cardcenter.ch> on 2011/02/24 07:50:51 UTC

Compile Subversion 1.6.5 on SLES 11.1

Hello everybody,
 
I have problems compiling Subversion with Apache support on SLES 11.1 it says the zlib should be compiled with -fPIC flag. It is the version which came with subversion which i have intalled into /opt/zlib isn't this supposed to be working alright? Can maybe somebody give me a good Guide which has all the steps in it or tell me what i'am doing wrong? I have read the "-fPIC" Error Site from Gentoo because this was the site google was spitting out but i seem to have lack of understanding about the makefiles and where to place this -fPIC argument if it is really required. 
 
Thanks already for the help provided.
 
 
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3#doc_chap2 


Code Listing 6.1: A sample error message
libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC .libs/assert.o: could not read symbols: Bad value

This means that the file assert.o was not compiled with the -fPIC flag, which it should. When you fix this kind of error, make sure only objects that are used in shared libraries are compiled with -fPIC. 
Here is my workstep of course i have fixed already many of the library issues which i hadn't installed on the system eg. RSA_new ect.
/configure --prefix=/opt/subversion --with-ssl --with-zlib=/opt/zlib
 
make all ....
 
*skipped*
 
/bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE  -g -O2  -g -O2 -pthread   -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include   -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/utf_validate.lo -c subversion/libsvn_subr/utf_validate.c
/bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE  -g -O2  -g -O2 -pthread   -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include   -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/validate.lo -c subversion/libsvn_subr/validate.c
/bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE  -g -O2  -g -O2 -pthread   -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include   -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/version.lo -c subversion/libsvn_subr/version.c
/bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE  -g -O2  -g -O2 -pthread   -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include   -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/win32_crashrpt.lo -c subversion/libsvn_subr/win32_crashrpt.c
/bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE  -g -O2  -g -O2 -pthread   -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include   -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/win32_crypto.lo -c subversion/libsvn_subr/win32_crypto.c
/bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE  -g -O2  -g -O2 -pthread   -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include   -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/win32_xlate.lo -c subversion/libsvn_subr/win32_xlate.c
/bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE  -g -O2  -g -O2 -pthread   -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include   -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/xml.lo -c subversion/libsvn_subr/xml.c
cd subversion/libsvn_subr && /bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=link gcc  -g -O2  -g -O2 -pthread   -L/opt/zlib/lib  -rpath /opt/subversion/lib -o libsvn_subr-1.la  atomic.lo auth.lo cache-inprocess.lo cache-memcache.lo cache.lo checksum.lo cmdline.lo compat.lo config.lo config_auth.lo config_file.lo config_win.lo constructors.lo ctype.lo date.lo deprecated.lo dirent_uri.lo dso.lo error.lo hash.lo io.lo iter.lo kitchensink.lo lock.lo log.lo macos_keychain.lo md5.lo mergeinfo.lo nls.lo opt.lo path.lo pool.lo prompt.lo properties.lo quoprint.lo sha1.lo simple_providers.lo skel.lo sorts.lo sqlite.lo ssl_client_cert_providers.lo ssl_client_cert_pw_providers.lo ssl_server_trust_providers.lo stream.lo subst.lo svn_base64.lo svn_string.lo target.lo time.lo user.lo username_providers.lo utf.lo utf_validate.lo validate.lo version.lo win32_crashrpt.lo win32_crypto.lo win32_xlate.lo xml.lo /tmp/subversion/subversion-1.6.5/apr-util/libaprutil-1.la     -lexpat /tmp/subversion/subversion-1.6.5/apr/libapr-1.la -lrt -lcrypt  -lpthread -ldl  -lz
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /opt/zlib/lib/libz.a(deflate.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/opt/zlib/lib/libz.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1


Based on previous e-mail correspondence with you and/or an agreement reached with you, we consider ourselves authorized to contact you via unsecured e-mail. 
Warning: 
(a) E-mails can involve SUBSTANTIAL RISKS, e.g. lack of confidentiality, potential manipulation of contents and/or sender's address, incorrect recipient (misdirection), viruses etc. We assume no responsi-bility for any loss or damage resulting from the use of e-mails. We recommend in particular that you do NOT SEND ANY SENSITIVE INFORMATION, that you do not include details of the previous message in any reply, and that you enter e-mail address(es) manually every time you write an e-mail. 
(b) As a matter of principle, we do NOT accept any ORDERS, revocations of orders or authorizations, blocking of credit cards, etc., sent by e-mail Should such an e-mail nevertheless be received, we are not obliged to act on or respond to the e-mail. 
Please notify us immediately if you received this e-mail by mistake or if you do not wish to receive any further e-mail correspondence. If you have received this e-mail by mistake, please completely delete it (and any attachments) and do not forward it or inform any other person of its contents.

Re: Compile Subversion 1.6.5 on SLES 11.1

Posted by Sperling Stefan <st...@elego.de>.
On Thu, Feb 24, 2011 at 11:45:04AM +0100, Sperling Stefan wrote:
> On Thu, Feb 24, 2011 at 11:07:35AM +0100, Stutz Oliver wrote:
> > Hi Stefan,
> >  
> > Thanks for your many replies.
> >  
> > The Reason why i want to doit like that is because SLES 11.1
> > Subversion from the repository is not available. (We use a company
> > internal SLES repository which is under specific company restrictions
> > & security policies) but if you can confirm to me that the packages
> > provided in the email will work on 11.1 without an upgrade to 11.2 or
> > 11.3
> 
> 
> There doesn't seem to be any SLES 11.2 or later release.
> SLES 11.1 is the latest (it's labelled as "SLES 11 service pack 1"
> on the novell website).
> 
> There aren't any separate Subversion package repositories for point
> releases of any SLES version on the build service.
> I suppose that's because all the point releases seem to contain is
> security and bug fixes. Browsing the release notes for 11.1 at
> http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11-SP1/
> there don't seem to be any changes that would prevent subversion
> packages compiled for SLES 11 to stop working on SLES 11.1.
> The list at http://en.opensuse.org/openSUSE:Build_Service_supported_build_targets
> doesn't list SLES 11.1 separately either.
> 
> > I would be very happy (it would be awesome and safe worktime).
> 
> Not only does it save time, it also makes it easier to get important
> bugfixes quickly. The packages on the build service are kept up-to-date.
> Whenever a new Subversion release is made, there will be a corresponding
> update on the buildservice a few days later (and especially fast if the
> new Subversion release fixes security issues). You can receive this update
> via yast just like any other update.

I forgot to mention one thing:

You might also want to check if using packages from the buildservice
has any effect on support agreements with Novell.
I don't know anything about that, because I'm not a Novell employee nor
a SUSE developer. I'm just helping out with maintaining the packages
created by the buildservice. Those packages eventually end up in new
SLES distribution releases, but I have no idea what Novell's policy is
on support for packages from the buildservice for existing SLES releases.

The same concerns about support might apply to self-compiled binaries, BTW.
It's even possible that Novell prefers that customers use buildservice
binaries instead of compiling their own. But I don't know. Ask them :)

Novel is likely to independently backport security fixes to the Subversion
release they're suppoting. So you should only use buildservice packages if
they contains fixes for problems that affect you and which standard SLES 11
updates do not provide fixes for. I suppose this is the case as you'd
otherwise not try to compile your own binaries in the first place.

Re: Compile Subversion 1.6.5 on SLES 11.1

Posted by Sperling Stefan <st...@elego.de>.
On Thu, Feb 24, 2011 at 11:07:35AM +0100, Stutz Oliver wrote:
> Hi Stefan,
>  
> Thanks for your many replies.
>  
> The Reason why i want to doit like that is because SLES 11.1
> Subversion from the repository is not available. (We use a company
> internal SLES repository which is under specific company restrictions
> & security policies) but if you can confirm to me that the packages
> provided in the email will work on 11.1 without an upgrade to 11.2 or
> 11.3


There doesn't seem to be any SLES 11.2 or later release.
SLES 11.1 is the latest (it's labelled as "SLES 11 service pack 1"
on the novell website).

There aren't any separate Subversion package repositories for point
releases of any SLES version on the build service.
I suppose that's because all the point releases seem to contain is
security and bug fixes. Browsing the release notes for 11.1 at
http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11-SP1/
there don't seem to be any changes that would prevent subversion
packages compiled for SLES 11 to stop working on SLES 11.1.
The list at http://en.opensuse.org/openSUSE:Build_Service_supported_build_targets
doesn't list SLES 11.1 separately either.

> I would be very happy (it would be awesome and safe worktime).

Not only does it save time, it also makes it easier to get important
bugfixes quickly. The packages on the build service are kept up-to-date.
Whenever a new Subversion release is made, there will be a corresponding
update on the buildservice a few days later (and especially fast if the
new Subversion release fixes security issues). You can receive this update
via yast just like any other update.

Re: Compile Subversion 1.6.5 on SLES 11.1

Posted by Stutz Oliver <Ol...@cardcenter.ch>.
Hi Stefan,
 
Thanks for your many replies.
 
The Reason why i want to doit like that is because SLES 11.1 Subversion from the repository is not available. (We use a company internal SLES repository which is under specific company restrictions & security policies) but if you can confirm to me that the packages provided in the email will work on 11.1 without an upgrade to 11.2 or 11.3 I would be very happy (it would be awesome and safe worktime).
 
Thanks,
 
Oliver
 

>>> Stefan Sperling <st...@elego.de> 2/24/2011 10:29 am >>>
On Thu, Feb 24, 2011 at 07:50:51AM +0100, Stutz Oliver wrote:
> Hello everybody,
>  
> I have problems compiling Subversion with Apache support on SLES 11.1 it says the zlib should be compiled with -fPIC flag. It is the version which came with subversion which i have intalled into /opt/zlib isn't this supposed to be working alright? Can maybe somebody give me a good Guide which has all the steps in it or tell me what i'am doing wrong? I have read the "-fPIC" Error Site from Gentoo because this was the site google was spitting out but i seem to have lack of understanding about the makefiles and where to place this -fPIC argument if it is really required. 
>  
> Thanks already for the help provided.
>  

> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /opt/zlib/lib/libz.a(deflate.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
> /opt/zlib/lib/libz.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1

No idea.

Any reason you're not using the latest Subversion binaries from the
OpenSUSE/SLES buildservice (apart from the fact that it seems to be down at
the moment)? Those binaries are maintained by SUSE developers with help
from other people (including myself), have been automatically packaged and
tested and are ready to be installed via yast. They are of the same
quality as can be expected from the Subversion packages that ship on
the distribution media.

If you are going to go through the effort of building your own binaries,
1.6.5 seems like an odd choice. You might as well try to build 1.6.15
which is the current stable release.


Based on previous e-mail correspondence with you and/or an agreement reached with you, we consider ourselves authorized to contact you via unsecured e-mail. 
Warning: 
(a) E-mails can involve SUBSTANTIAL RISKS, e.g. lack of confidentiality, potential manipulation of contents and/or sender's address, incorrect recipient (misdirection), viruses etc. We assume no responsi-bility for any loss or damage resulting from the use of e-mails. We recommend in particular that you do NOT SEND ANY SENSITIVE INFORMATION, that you do not include details of the previous message in any reply, and that you enter e-mail address(es) manually every time you write an e-mail. 
(b) As a matter of principle, we do NOT accept any ORDERS, revocations of orders or authorizations, blocking of credit cards, etc., sent by e-mail Should such an e-mail nevertheless be received, we are not obliged to act on or respond to the e-mail. 
Please notify us immediately if you received this e-mail by mistake or if you do not wish to receive any further e-mail correspondence. If you have received this e-mail by mistake, please completely delete it (and any attachments) and do not forward it or inform any other person of its contents.

Re: Compile Subversion 1.6.5 on SLES 11.1

Posted by Stefan Sperling <st...@elego.de>.
On Thu, Feb 24, 2011 at 10:29:24AM +0100, Stefan Sperling wrote:
> Any reason you're not using the latest Subversion binaries from the
> OpenSUSE/SLES buildservice (apart from the fact that it seems to be down at
> the moment)?

Looks like they've fixed it.
Here's a link to latest Subversion packages for SLE 11:
https://build.opensuse.org/package/binaries?package=subversion&project=devel%3Atools%3Ascm%3Asvn&repository=SLE_11
If you add the repository linked from this page to yast you can
install the packages via yast.

Re: Compile Subversion 1.6.5 on SLES 11.1

Posted by Stefan Sperling <st...@elego.de>.
On Thu, Feb 24, 2011 at 07:50:51AM +0100, Stutz Oliver wrote:
> Hello everybody,
>  
> I have problems compiling Subversion with Apache support on SLES 11.1 it says the zlib should be compiled with -fPIC flag. It is the version which came with subversion which i have intalled into /opt/zlib isn't this supposed to be working alright? Can maybe somebody give me a good Guide which has all the steps in it or tell me what i'am doing wrong? I have read the "-fPIC" Error Site from Gentoo because this was the site google was spitting out but i seem to have lack of understanding about the makefiles and where to place this -fPIC argument if it is really required. 
>  
> Thanks already for the help provided.
>  

> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /opt/zlib/lib/libz.a(deflate.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
> /opt/zlib/lib/libz.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1

No idea.

Any reason you're not using the latest Subversion binaries from the
OpenSUSE/SLES buildservice (apart from the fact that it seems to be down at
the moment)? Those binaries are maintained by SUSE developers with help
from other people (including myself), have been automatically packaged and
tested and are ready to be installed via yast. They are of the same
quality as can be expected from the Subversion packages that ship on
the distribution media.

If you are going to go through the effort of building your own binaries,
1.6.5 seems like an odd choice. You might as well try to build 1.6.15
which is the current stable release.