I'll be glad to fix any problems resulting from a bad build, but so far
I'm not seeing the problem.
I just checked version 1.1.1 on the machine it was built on
(dsummers.digital-realms.com) which is a RedHat 9.0 machine. It only has
db4-4.0.14-20 installed. No BDB 4.2.52 in sight. So I'm not seeing how
you are seeing it linked to multiple versions of BDB.
Can you give me a transcript of the command you are using to see this?
Here is mine:
$ ldd /usr/bin/svn
libsvn_client-1.so.0 => /usr/lib/libsvn_client-1.so.0 (0x40016000)
libsvn_wc-1.so.0 => /usr/lib/libsvn_wc-1.so.0 (0x40039000)
libsvn_ra-1.so.0 => /usr/lib/libsvn_ra-1.so.0 (0x4005f000)
libsvn_diff-1.so.0 => /usr/lib/libsvn_diff-1.so.0 (0x40062000)
libsvn_ra_local-1.so.0 => /usr/lib/libsvn_ra_local-1.so.0 (0x40068000)
libsvn_repos-1.so.0 => /usr/lib/libsvn_repos-1.so.0 (0x4006d000)
libsvn_fs-1.so.0 => /usr/lib/libsvn_fs-1.so.0 (0x40084000)
libsvn_fs_fs-1.so.0 => /usr/lib/libsvn_fs_fs-1.so.0 (0x4008a000)
libsvn_fs_base-1.so.0 => /usr/lib/libsvn_fs_base-1.so.0 (0x400a1000)
libsvn_ra_svn-1.so.0 => /usr/lib/libsvn_ra_svn-1.so.0 (0x400c2000)
libsvn_ra_dav-1.so.0 => /usr/lib/libsvn_ra_dav-1.so.0 (0x400d1000)
libsvn_delta-1.so.0 => /usr/lib/libsvn_delta-1.so.0 (0x400e5000)
libsvn_subr-1.so.0 => /usr/lib/libsvn_subr-1.so.0 (0x400ed000)
libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x40112000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x40128000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x40153000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4015e000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40165000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4021f000)
libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x4022e000)
librt.so.1 => /lib/tls/librt.so.1 (0x4024f000)
libm.so.6 => /lib/tls/libm.so.6 (0x40261000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40283000)
libnsl.so.1 => /lib/libnsl.so.1 (0x402b0000)
libneon.so.24 => /usr/lib/libneon.so.24 (0x402c5000)
libssl.so.4 => /lib/libssl.so.4 (0x402df000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x40314000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40405000)
libdl.so.2 => /lib/libdl.so.2 (0x40417000)
libz.so.1 => /usr/lib/libz.so.1 (0x4041b000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0x40429000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x4043d000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x4049b000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x404ab000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x404ad000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x404ce000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libpam.so.0 => /lib/libpam.so.0 (0x404d9000)
$ ldd /usr/bin/svnadmin
libsvn_repos-1.so.0 => /usr/lib/libsvn_repos-1.so.0 (0x40016000)
libsvn_fs-1.so.0 => /usr/lib/libsvn_fs-1.so.0 (0x4002e000)
libsvn_fs_fs-1.so.0 => /usr/lib/libsvn_fs_fs-1.so.0 (0x40033000)
libsvn_fs_base-1.so.0 => /usr/lib/libsvn_fs_base-1.so.0 (0x4004a000)
libsvn_delta-1.so.0 => /usr/lib/libsvn_delta-1.so.0 (0x4006b000)
libsvn_subr-1.so.0 => /usr/lib/libsvn_subr-1.so.0 (0x40073000)
libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x40097000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x400ae000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x400d9000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x400e4000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x400eb000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401a5000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x401b3000)
libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x401d4000)
librt.so.1 => /lib/tls/librt.so.1 (0x401f5000)
libm.so.6 => /lib/tls/libm.so.6 (0x40207000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40229000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40256000)
libdl.so.2 => /lib/libdl.so.2 (0x4026b000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40270000)
libssl.so.4 => /lib/libssl.so.4 (0x4027b000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x402b0000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libpam.so.0 => /lib/libpam.so.0 (0x403a2000)
libresolv.so.2 => /lib/libresolv.so.2 (0x403aa000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0x403bc000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x403cf000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x4042d000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x4042f000)
libz.so.1 => /usr/lib/libz.so.1 (0x40440000)
As you can see, no DB 4.2.X in sight there.
Please let me know. I'm sure sorry you ran into problems!
...off to check version 1.0.9..........
- David Summers
On Fri, 26 Nov 2004, Ben Collins-Sussman wrote:
> For dev@ folks not reading the users@ list, it looks like David
> Summers' RPMS are bogus. David, maybe you should fix them, rebuild
> them? Maybe we should take down the link from our downloads page?
>
> The full users@ thread is here:
>
> http://svn.haxx.se/users/archive-2004-11/1295.shtml
>
>
>
> Begin forwarded message:
>
> > From: Gary Thomas <gary@mlbassoc.com>
> > Date: November 26, 2004 4:18:25 PM CST
> > To: Max Bowsher <maxb@ukf.net>
> > Cc: users@subversion.tigris.org
> > Subject: Re: Is subversion safe to use?
> >
> > On Fri, 2004-11-26 at 13:55, Max Bowsher wrote:
> >> Gary Thomas wrote:
> >>> Sure (although I sent all of this yesterday).
> >>>
> >>> Red Hat 9.0
> >>> Old version - 1.0.9
> >>> New version - 1.1.1
> >>> Any access method - they all fail :-(
> >>> Upgraded via RPM packages found on http://summersoft.fay.ar.us/
> >>
> >> I've just had a look at those packages.
> >>
> >> They seem to be linked *two* versions of Berkeley DB simultaneously.
> >> This
> >> has very disturbing implications for their reliability - I recommend
> >> you
> >> discontinue use of them immediately - or at least only use them for
> >> FSFS
> >> repositories.
> >
> > Well, they were the RPM packages recommended on the subversion download
> > page :-)
> >
> >>
> >> Recovering your old repositories is 99.9% likely to be possible.
> >>
> >> Either:
> >> Build subversion from source against the appropriate version of BDB
> >> (sounds
> >> like 4.2 from your mentions of set_flags errors)
> >>
> >> Or:
> >> Put a tarball of your repository on a web/ftp site, and email me the
> >> URL,
> >> I'll get a dumpfile back to you in the same way.
> >
> > The repository is actually quite large - the result of converting 3
> > years of my consulting work on multiple systems from CVS to SVN. I
> > have
> > been able to reconstruct the work I did over this week, so it's not
> > 100%
> > necessary to do this.
> >
> > That said, I've switched to FSFS repositories. I really want to feel
> > good about using SVN and hope that this won't happen to me again in
> > the future.
> >
> > --
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 27 00:41:29 2004