RE: svn RH7x packages vs. RH7.2

On Tue, 1 Jun 2004, Paul Nash wrote:

> Thanks for your response. I think I understand what's happening a little
> bit more now, after much gymnastics and an ill-fated attempt to build some
> of the project myself. Actually, I was able to make everything by pulling
> down a source tarball, but since I didn't have db4-devel installed, I got a
> client only build. Fine for my purposes, but then when I tried a "make
> install" (as root or with a DESTDIR) a bunch of the libsvn relinks failed
> for some reason. So I gave up on that route for now.
>
> It appears that the 1.0.2 packages are fine, but the neon 0.24.6-1 package
> in the 1.0.3 subdir has the depends problem. It Requires: GLIBC2_3. I was
> hoping to install the latest and greatest available, that being 1.0.3 (there
> aren't any 1.0.4 packages up yet...) but I guess for now I'll go with a
> slightly older client. Of course I'm not terribly happy about this, given
> the security bug, but it works for my immediate needs. Since I have gotten
> far enough to build libneon, perhaps I'll try upgrading just that part.
> HTH...

That's wierd.

$ rpm -q neon
neon-0.24.6-1

$ rpm -q --requires neon
expat
zlib >= 1.1.4
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
ld-linux.so.2
libcrypto.so.2
libc.so.6
libdl.so.2
libexpat.so.0
libssl.so.2
libz.so.1
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)

Let me know if I can help out with anything (as I have time, of course).

If someone has a RedHat 7.2 system that I could log on to then I might be
able to build my RPMs on that system. Root access should not be needed.
 
> -----Original Message-----
> From: David Summers [mailto:david@summersoft.fay.ar.us]
> Sent: Sunday, May 30, 2004 10:37 AM
> To: Paul Nash
> Subject: Re: svn RH7x packages vs. RH7.2
>
>
>
> On Fri, 28 May 2004, Paul Nash wrote:
>
> > I was wondering if you could tell me what your recommendation is to use
> the
> > subversion RH7x binary rpms with RH7.2. The problem I have with them is
> > that they are apparently built against glibc-2.3, amongst other things,
> and
> > that isn't available through the updates RH has released to 7.2 or even
> 7.3.
> > I got it to work on one machine I had, eventually, by upgrading about half
> > the packages (used RH8.0 packages, after upgrading rpm itself to 4.0.4,
> plus
> > other stuff, plus...YUK).
>
> I'd be glad to help out if I can. As far as I know I just have a RH 7.3
> generic install with no updates to build the 7.X RPMs. Before I switched
> my server from 7.2 to 7.3 a year or so ago the RPMs were working fine for
> me on 7.2. I just checked and my RH 7.3 system has glibc-2.2.5-43 on it.
> I can send you a "rpm -qa" of my RH7.3 system if you are interested.
> If it is not working on 7.2 then I suggest you take my source RPMs and
> re-compile them on 7.2.
>
> You might first start with neon and make sure you can compile that. It is
> pretty easy to compile. Then do apache with APR and APR-UTILS. You can
> take that from my (S)RPMs and should be able to compile that. Once that
> is done then go for Subversion. Subversion has some other pre-requisites
> because I do the documentation, python, etc.
>
> Keep me posted and I'll try to step you though stuff.
>
>
> > Anyway, my problem is that all our development workstations
> have a
> > standardized package set, and we test our software running standard builds
> > against the same glibc everywhere, because it's similar to the version of
> > glibc shipping on our embedded device. So I don't really want to upgrade
> > everybody's clients.
> >
> > Could you maybe help me figure out a set of steps so that I can rebuild
> > these packages locally to be linked against older RH7.2 libraries so
> > everyone else can install them with no speed bumps? Thx...
> >
> > -Paul
> >
> >
>
>

-- 
David Wayne Summers          "Linux: Because reboots are for hardware upgrades!"
david_at_summersoft.fay.ar.us   PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint =  C0 E0 4F 50 DD A9 B6 2B  60 A1 31 7E D2 28 6D A8 
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org