[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Bad database version: compiled with 4.2.52, running against 4.1.25

From: Måns Tånneryd <mans_at_tanneryd.com>
Date: 2004-04-23 20:31:10 CEST

Oupps!

It seems as if I was running httpd-2.0.48-1.2 instead of httpd-2.0.48-1.2.1
(David Summers version) and that was what caused it all. Davids version of
httpd worked just as fine as 2.0.49. Sorry for spamming you with my
stupidity.

/Måns

> -----Original Message-----
> From: Måns Tånneryd [mailto:mans@tanneryd.com]
> Sent: den 23 april 2004 20:21
> To: users@subversion.tigris.org
> Subject: RE: Bad database version: compiled with 4.2.52, running against
> 4.1.25
>
>
> Well. I'm confused.
>
> Running ldd on /usr/sbin/httpd (httpd-2.0.48-1.2) returned:
> libssl.so.4 => /lib/libssl.so.4 (0x00138000)
> libcrypto.so.4 => /lib/libcrypto.so.4 (0x005f5000)
> libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0018f000)
> libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00971000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0x00891000)
> libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00111000)
> libresolv.so.2 => /lib/libresolv.so.2 (0x0016d000)
> libz.so.1 => /usr/lib/libz.so.1 (0x002ec000)
> libpcre.so.0 => /lib/libpcre.so.0 (0x008a9000)
> libpcreposix.so.0 => /usr/lib/libpcreposix.so.0 (0x00c61000)
> libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x0050a000)
> libldap.so.2 => /usr/lib/libldap.so.2 (0x001a2000)
> liblber.so.2 => /usr/lib/liblber.so.2 (0x0087a000)
> libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x00d92000)
> libdb-4.1.so => /lib/tls/libdb-4.1.so (0x00e7e000)
> libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0017f000)
> libexpat.so.0 => /usr/lib/libexpat.so.0 (0x001d4000)
> libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x00249000)
> librt.so.1 => /lib/tls/librt.so.1 (0x0040d000)
> libm.so.6 => /lib/tls/libm.so.6 (0x001f4000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x00280000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x0031e000)
> libdl.so.2 => /lib/libdl.so.2 (0x00dc3000)
> libc.so.6 => /lib/tls/libc.so.6 (0x00adc000)
> libdb-4.2.so => /lib/tls/libdb-4.2.so (0x00333000)
> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00216000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00930000)
>
> It seems to be linked with both libdb-4.1.so and libdb-4.2.so. If I
> understand things correctly the symbols in these two libs are the
> same which
> would mean that anything compiled against 4.2 would end up trying
> to use 4.1
> since it is placed "before" 4.2, failing miserably. That would explain why
> it complains the way it does.
>
> Installing httpd-2.0.49-2 and running ldd again yields:
> libpcre.so.0 => /lib/libpcre.so.0 (0x00982000)
> libpcreposix.so.0 => /usr/lib/libpcreposix.so.0 (0x0028d000)
> libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x00c38000)
> libldap.so.2 => /usr/lib/libldap.so.2 (0x0039f000)
> liblber.so.2 => /usr/lib/liblber.so.2 (0x00cb5000)
> libdb-4.2.so => /lib/tls/libdb-4.2.so (0x00af2000)
> libexpat.so.0 => /usr/lib/libexpat.so.0 (0x0083e000)
> libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x007f0000)
> librt.so.1 => /lib/tls/librt.so.1 (0x004c7000)
> libm.so.6 => /lib/tls/libm.so.6 (0x006c0000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x00111000)
> libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0013e000)
> libdl.so.2 => /lib/libdl.so.2 (0x00f64000)
> libc.so.6 => /lib/tls/libc.so.6 (0x0014e000)
> libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x00290000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x00d1f000)
> libresolv.so.2 => /lib/libresolv.so.2 (0x00790000)
> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x005ad000)
> libssl.so.4 => /lib/libssl.so.4 (0x00297000)
> libcrypto.so.4 => /lib/libcrypto.so.4 (0x003d1000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00930000)
> libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00d69000)
> libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x002cc000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0x00583000)
> libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00333000)
> libz.so.1 => /usr/lib/libz.so.1 (0x00355000)
>
> libdb-4.1.so is GONE as are all problems with subversion!!!
>
> Confusion #1: If my above reasoning is correct am I the only one trying to
> use subversion on 2.0.48? If not, shouldn't everyone else experience the
> same problem?
>
> Confusion #2: Why would 2.0.48 be linked against two versions of
> berkely db?
> (I'm not super savvy on linking issues in Linux systems so I'm fumbling
> here...)
>
> Any attempts to enlighten me on this subject would be greatly appreciated.
>
> /Måns
>
> > -----Original Message-----
> > From: Måns Tånneryd [mailto:mans@tanneryd.com]
> > Sent: den 30 mars 2004 22:44
> > To: users@subversion.tigris.org
> > Subject: Bad database version: compiled with 4.2.52, running against
> > 4.1.25
> >
> >
> > Hi!
> >
> > I tried to upgrade subversion from 0.37 to 1.0.1 on a Fedora OS
> > but ran into
> > db4 related problems. The apache error log says it, mod_dav_svn i
> > assume, is
> > compiled against 4.2.52 but is running against 4.1.25. I have
> both 4.1.25
> > and 4.2.52 installed and as far as I understand they have no identically
> > named files so they should be able to live side by side. Anyone
> else seen
> > anything similar?
> >
> > I have the following installed:
> > httpd-2.0.48-1.2
> > db4-devel-4.1.25-14
> > db4-4.1.25-14
> > db42-4.2.52-0.1
> > db4-utils-4.1.25-14
> > subversion-server-1.0.1-1
> > subversion-1.0.1-1
> > apr-0.9.5-0.3
> > apr-util-0.9.5-0.4
> > neon-0.24.4-1
> >
> >
> > Any and all help much appreciated!!
> >
> > /Måns
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 23 20:28:36 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.