Bug 59394 - Building RPM 4.0.4 from Source (Available Mutex?)
Building RPM 4.0.4 from Source (Available Mutex?)
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.2
strongarm Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-06 17:04 EST by Noam Rathaus
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-06 17:04:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Noam Rathaus 2002-02-06 17:04:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)

Description of problem:
Trying to compile the source pacakge results in a failure due to incorrect 
Mutex type. I am not able to find any working Mutex to use for the StrongARM 
architecutre.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Get the latest pacakge
2. Open it up in a directory
3. Using Intrinsync's StrongArm enviroment:

Run:
export CXX=gcc
export CC=gcc
export ac_cv_sizeof_char=1 \
ac_cv_sizeof_unsigned_char=1 \
ac_cv_sizeof_short=2 \
ac_cv_sizeof_unsigned_short=2 \
ac_cv_sizeof_int=4
export ac_cv_sizeof_long=4 \
ac_cv_sizeof_long_long=8 \
ac_cv_sizeof_unsigned_long_long=8 \
ac_cv_sizeof_float=4
export ac_cv_sizeof_double=8 \
db_cv_alignp_t=set \
db_cv_alignp_t="unsigned int"
export db_cv_fcntl_f_setfd=yes \
db_cv_sprintf_count=no \ 
db_cv_mutex="ia64/gcc-assembly"

(I tried, x86/gcc-assembly, ALPHA/gcc-assembly, ia64/gcc-assembly, and others)

export PATH=/root/Intrinsyc/arm-linux/bin:/root/Intrinsync/bin:$PATH
./configure --build=i386-linux --host=arm-linux --disable-aio 


Actual Results:  Different combinations of the same error:
/tmp/ccsmWE1E.s: Assembler messages:
/tmp/ccsmWE1E.s:85: Error: bad instruction `xchg1 r3=[r4,#0],r1'
make: *** [mut_tas.lo] Error 1

../mutex/mut_tas.c: In function `__db_tas_mutex_lock':
../mutex/mut_tas.c:109: inconsistent operand constraints in an `asm'

Expected Results:  Getting the binaries?! :)

Additional info:

I downloaded the latest stable and development package off www.rpm.org (4.0.4)
Comment 1 Jeff Johnson 2002-02-06 17:18:32 EST
You're on an arm platform, you're gonna need arm
assembly voo-doo for a test-and-set mutex, no other platform's
assembly language will do.

Try looking in libpthread for arm specific mutexes, or ask an ARM
developer on an arm-specific mailing list for the Right Thing To Do.

Sorry, ARM is not a platform that's available to me, so I can't
undertake a fix flying blind, as it were. Please reopen this
bug if you have a patch for rpm on arm, however, I'll be
happy to integrate a known good patch
Comment 2 Noam Rathaus 2002-02-06 17:23:50 EST
Wow, well Debian has been nicer with their reply, and they have one of their 
own, so I guess I will just move there.

If you will be kind enough to look into their's available here:
http://ftp.de.debian.org/debian/dists/woody/main/binary-arm/pool/main/r/rpm/
Comment 3 Noam Rathaus 2002-02-06 17:24:52 EST
Wrong URL:
http://ftp.debian.org/debian/pool/main/r/rpm/
Comment 4 Jeff Johnson 2002-02-06 17:35:41 EST
Thanks for the pointer. Here's what I find

+
+The rpm source also includes (but is not built using) a copy of db3, which has
+a BSD license (db/LICENSE in the source tree).
+

as it's db[34], not rpm, what needs the arm patch.
Comment 5 Jeff Johnson 2002-02-06 17:44:53 EST
And I do not see an arm mutex patch at
../../d/db3/db3_3.2.9.patch.gz
(relative to the URL you've given me).

Again, if there's a patch, I'll be happy to integrate
into the db-4.0.14 code within rpm. I have no way of
testing still ...
Comment 6 Jeff Johnson 2002-02-06 18:57:03 EST
Here's the arm asm voo-doo AFAICT:

However your path of least resistance is gonna be to
configure the internal db-4.0.14 with --enable-posixmutexes
to use the mutexes from libpthread.

Have fun with Debian however, I still cannot test the
above.


int
__pthread_spin_lock (pthread_spinlock_t *lock)
{
  unsigned int val;

  do
    asm volatile ("swp %0, %1, [%2]"
                  : "=r" (val)
                  : "0" (1), "r" (lock)
                  : "memory");
  while (val != 0);

  return 0;
}
weak_alias (__pthread_spin_lock, pthread_spin_lock)


int
__pthread_spin_trylock (pthread_spinlock_t *lock)
{
  unsigned int val;

  asm volatile ("swp %0, %1, [%2]"
                : "=r" (val)
                : "0" (1), "r" (lock)
                : "memory");

  return val ? EBUSY : 0;
}
weak_alias (__pthread_spin_trylock, pthread_spin_trylock)


int
__pthread_spin_unlock (pthread_spinlock_t *lock)
{
  return *lock = 0;
}
weak_alias (__pthread_spin_unlock, pthread_spin_unlock)

Note You need to log in before you can comment on or make changes to this bug.