subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Problems compiling 1.7.0 on redhat el4 64bit
Date Tue, 09 Aug 2011 19:24:56 GMT
Unfortunately, some of us don't have a choice what version of linux we have to run on.  I end
up compiling almost all the dependencies for subversion myself.  I guess I'll need to track
down exactly what change in the development process started breaking things.  For now, we
have a solution where I've compiled on 32bit with support for libmagic manually removed.

As a side note, it would be nice to actually be able to add a --without-libmagic and have
the configure script work without hacking.  The release notes even say libmagic is optional,
but the way I see it currently, the only we the default configure won't use it is if your
build machine doesn't have libmagic installed.

-----Original Message-----
From: Nico Kadel-Garcia [] 
Sent: Tuesday, August 09, 2011 12:59 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit

On Mon, Aug 8, 2011 at 6:19 PM,  <> wrote:
> For a while I was downloading and running the development build of 
> subversion 1.7.0.  At one revision of the code I started having an 
> issue where svn would immediately segfault.  At that time I stopped 
> using 1.7.0 assuming the issue would be fixed before release.  
> Unfortunately I just downloaded the beta2 release of 1.7.0 and I'm having the same problem.
> Interestingly enough I can successfully build beta2 on one of our 
> 32bit systems, but I can't use that build on our 64 bit systems 
> because it tries to link against the 32bit version of libmagic.

RHEL 4 is, frankly, way too old to support with new tools. It's initial release was over six
years, and far too many core libraries, such as swig and sqlite and python, have not gotten
updated to match subversion requirements.

I'm trying to rebundle an SRPM for 1.6.17 for the RPMforge repository, and no way am I burning
the cycles to get it back to RHEL 4. The
1.7.0beta3 releases will compile well enough on RHEL 5, especially if you build from an SRPM
for 1.6.x first to get most of the dependencies resolved.

RHEL 5, and Scientific Linux 5, have subversion-1.6.11 available from the upstream vendor.
Would that be enough for you?

View raw message