Please be aware that there is a bug with mutexes in DB 4.0 (actually I
think anything newer than 3.1) on Mac OS X.
Keith Bostic provided the following patch for DB 4.0.14. I don't
believe that sleepycat has released this publicly yet.
*** dbinc/mutex.h.orig Wed Apr 10 14:50:05 2002
--- dbinc/mutex.h Wed Dec 31 19:00:00 1969
***************
*** 510,532 ****
* 'set' mutexes have the value 1, like on Intel; the returned value
from
* MUTEX_SET() is 1 if the mutex previously had its low bit clear, 0
otherwise.
*/
! #define MUTEX_SET(tsl) ({ \
! int __one = 1; \
! int __r; \
! tsl_t *__l = (tsl); \
! asm volatile (" \
! 0: \
! lwarx %0,0,%1; \
! cmpwi %0,0; \
! bne 1f; \
! stwcx. %2,0,%1; \
! bne- 0b; \
! 1:" \
! : "=&r" (__r) \
! : "r" (__l), "r" (__one)); \
! !(__r & 1); \
! })
!
#define MUTEX_UNSET(tsl) (*(tsl) = 0)
#define MUTEX_INIT(tsl) MUTEX_UNSET(tsl)
#endif
--- 510,536 ----
* 'set' mutexes have the value 1, like on Intel; the returned value
from
* MUTEX_SET() is 1 if the mutex previously had its low bit clear, 0
otherwise.
*/
! extern int __db_mutex_set __P((volatile tsl_t *));
! static void
! __db_mutex_tas_dummy()
! {
! __asm__ __volatile__(" \n\
! .globl ___db_mutex_set \n\
! ___db_mutex_set: \n\
! lwarx r5,0,r3 \n\
! cmpwi r5,0 \n\
! bne fail \n\
! addi r5,r5,1 \n\
! stwcx. r5,0,r3 \n\
! beq success \n\
! fail: \n\
! li r3,0 \n\
! blr \n\
! success: \n\
! li r3,1 \n\
! blr");
! }
! #define MUTEX_SET(tsl) __db_mutex_set(tsl)
#define MUTEX_UNSET(tsl) (*(tsl) = 0)
#define MUTEX_INIT(tsl) MUTEX_UNSET(tsl)
#endif
On Thursday, June 13, 2002, at 04:29 AM, David Mankin wrote:
> On Wed, 12 Jun 2002, Garrett Rooney wrote:
>
>> On Wed, Jun 12, 2002 at 02:24:24PM -0700, David Mankin wrote:
>>> I'm having trouble getting a clean HEAD checkout to build on OS X.
>>>
>>> % svn-bootstrap up
>>> ...
>>> Updated to revision 2173.
>>> % (cd apr ; cvs up -d -P)
>>> % (cd apr-util ; cvs up -d -P)
>>> % configure --disable-shared --enable-maintainer-mode
>>> --with-berkeley-db=/sw
>>> ...
>>> % make
>>> ...
>>>
>>> I get many many errors like this:
>>> In file included from subversion/libsvn_fs/dag.c:27:
>>> subversion/libsvn_fs/dag.h:136: warning: declaration of `txn_id'
>>> shadows global declaration
>>> subversion/libsvn_fs/dag.h:162: warning: declaration of `txn_id'
>>> shadows global declaration
>>> subversion/libsvn_fs/dag.h:187: warning: declaration of `txn_id'
>>> shadows global declaration
>>>
>>> However, it keeps on trucking and building.
>>>
>>> Then it dies like this:
>>> subversion/libsvn_fs/fs.c: In function `cleanup_fs':
>>> subversion/libsvn_fs/fs.c:137: structure has no member named
>>> `txn_checkpoint'
>>> subversion/libsvn_fs/fs.c:142: structure has no member named
>>> `txn_checkpoint'
>>> make: *** [subversion/libsvn_fs/fs.lo] Error 1
>>>
>>> Anyone else having any trouble? Is there some step I forgot? Some
>>> file
>>> that's out of date? I have no trouble building the 0.12 tarball. I
>>> haven't tried the 0.13 tarball since the bootstrap client I had
>>> working
>>> seemed good enough to get HEAD so I could build from there. (Is this
>>> my
>>> problem?)
>>
>> it's finding the wrong berkeley db headers, you've probably got a
>> previous version of berkeley db somewhere on the system.
>>
>> -garrett
>
> Thanks, that helped a lot. In case this helps anybody else, this is the
> configure step that worked for me on OS X (not building a server
> though):
>
> ./configure --enable-maintainer-mode \
> --disable-shared \
> --with-berkeley-db=/sw/include/db4:/sw/lib
>
> This is with the current Fink CVS HEAD version, with db3-shlibs, db4,
> db4-bin, and db4-shlibs packages installed. I think it's strange that
> the current fink build of db4 puts its files & libraries where they are,
> but fortunately the --with-berkeley-db is flexible enough to handle it.
> (I had to find that in ./configure --help, rather than in INSTALL,
> however.)
>
> -David Mankin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 13 14:56:50 2002