Re: rpm, pthreads, and XScale

[Mark Hatle <fray mvista com>]

Eli Carter wrote:
> All,
>
> I'm still fighting with getting rpm to run on an ARM (XScale) system. If 
> anyone has any clues, I'd love to hear them...

The errors you have are all looking for nptl(Posix Thread library), 
AFAIK there is no nptl for any ARM systems yet (Linux Threads is still 
the most used).  (If there is, it's probably considered experimental.) 
You will need to inform "db" of the mutex type to use.  (Unfortunatly 
I'm not a db expert..)

--Mark

> "unable to initialize environment lock" appears to come from 
> rpm/db/env/env_region.c due to a call to __db_mutex_init() failing with 
> ENOSYS.  __db_mutex_init appears to be a macro for 
> __db_pthread_mutex_init() which appears to be defined in 
> db/mutex/mut_pthread.c.  __db_pthread_mutex_init() can return ENOSYS if 
> pthread_mutexattr_setpshared() or pthread_condattr_setpshared() returns 
> ENOSYS.
>
> So, using PTHREAD_PROCESS_SHARED results in ENOSYS.  Looking back at 
> __db_pthread_mutex_init() from db/mutex/mut_pthread.c, shows that rpm is 
> using PTHREAD_PROCESS_SHARED.  This is the only function that uses 
> ..._SHARED.
>
> For my ARM work, I'm looking at rpm 4.1 and glibc 2.3.1 and cross 
> compiling with gcc 3.2.1+, but Fedora Core has the same code in these 
> places and it works just fine.  How does the same code not generate 
> errors on my x86 box?  The way I read the code, it should return ENOSYS.
>
> I must be missing something.  But I can't see what, so at this point I'm 
> prepared to believe it's something dumb.  Anybody got a spare clue for me?