Enrique Perez-Terron wrote:
> On Mon, 2004-08-16 at 22:51, Enrique Perez-Terron wrote:
>> On Mon, 2004-08-16 at 21:56, Enrique Perez-Terron wrote:
>>> # rm -rf /home-4/subversion
>>> # svnadmin create /home-4/subversion
>>> svn: Berkeley DB error while creating environment for filesystem
>>> /home-4/subversion/db: Invalid argument
>>
>>
>> I have found the following code in db-4.2.52/env/env_open.c (with line
>> numbers):
>>
>> 139 #ifdef HAVE_MUTEX_THREAD_ONLY
>> 140 if (!LF_ISSET(DB_PRIVATE)) {
>> 141 __db_err(dbenv,
>> 142 "Berkeley DB library configured to support only DB_PRIVATE
>> environments"); 143 return (EINVAL);
>> 144 }
>> 145 #endif
>>
>> I have then checked if the string shown appears in the relevant
>> libraries, and it does. That indicates that my copy of db4 was compiled
>> with -DHAVE_MUTEX_THREAD_ONLY. This will make env_open() fail with
>> EINVAL unless called with DB_PRIVATE.
>>
>> I will subsequently check if it works to set the DB_PRIVATE flag in the
>> call to env_open(), but actually, I do not (yet) understand the
>> implications of doing so.
>
> After doing some reading I (too) have found it is no good idea. It makes
> subversion believe it has mutex protecion of critical sections when in
> reality it has not. If there are multiple simultaneous users of a
> repository, it may easily get corrupted.
>
> I have now found that the db4 rpm installs two versions of the library,
> one in /lib and one in /lib/tls. The rpm spec file only builds the tls
> version if running on an architecture that supports nptl (as defined in
> a static list)
>
> However, the postinstall script makes no attempt at checking if the
> present environment supports nptl, and so I am left with the notls
> version of the library.
>
> If I do a simple and naive ./configure, the script says
>
> checking for mutexes... x86/gcc-assembly
>
> and the produced db-config.h says
>
> #define HAVE_MUTEX_THREADS 1
> #define HAVE_MUTEX_X86_GCC_ASSEMBLY 1
>
> while the configure as run by rpm finds (in the tls case)
>
> checking for mutexes... (cached) POSIX/pthreads/library
>
> and in the notls case
>
> checking for mutexes... (cached) POSIX/pthreads/library/private
>
> and the corresponding contents of db_config.h is, in the tls case
>
> #define HAVE_MUTEX_PTHREADS 1
> #define HAVE_MUTEX_THREADS 1
>
> and in the notls case
>
> #define HAVE_MUTEX_PTHREADS 1
> #define HAVE_MUTEX_THREADS 1
> #define HAVE_MUTEX_THREAD_ONLY 1
>
> There appears to be a solution simply to ensure that the tls version of
> the library is used, adding /lib/tls and /usr/lib/tls to the top of
> /etc/ld.so.conf, and running ldconfig.
*BAD* idea. The tls variants are automatically used by the linker iff your
kernel supports NPTL.
> Rolling my own rpm is perhaps
> even better as the decision of the configure to use x86/gcc assembly
> likely is the best choice for my architecture.
>
> OK, now I configured the tls libs and got a new error message instead:
>
> svn: Berkeley DB error while creating environment for filesystem
> /home-4/subversion/db: Function not implemented
>
> But fortunately this is in the FAQ. I need a glibc that supports nptl.
> I386 does not support nptl, but i486 and i586 does. However, Fedora only
> ships glibc for i386 or i686, and I cannot use i686, so I have the i386
> non-nptl glibc version.
>
> Confusion snowballs faster than any clarification.
You could, in theory, rebuild glibc (ouch!).
Or, you could rebuild db, with --disable-posixmutexes.
This is likely the easiest option.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 17 10:21:53 2004