Bug 679489

The TEXTRELs are because opal/include/opal/sys/atomic.h has
/* OPAL_HAVE_INLINE_ATOMIC_*_32 will be 1 if <arch>/atomic.h provides
   a static inline version of it (in assembly).  If it's 0 but
   OPAL_HAVE_ATOMIC_CMPSET_32 is 1, then atomic_impl.h (below) will
   define a static inline version of it (in C, using
   atomic_cmpset_32()).  */                                        
#if OPAL_HAVE_INLINE_ATOMIC_ADD_32 || OPAL_HAVE_ATOMIC_CMPSET_32
static inline
#endif
int32_t opal_atomic_add_32(volatile int32_t *addr, int delta);
(and similarly for sub), but there is no definition in that header.
OPAL_HAVE_INLINE_ATOMIC_ADD_32 is 0, but OPAL_HAVE_ATOMIC_CMPSET_32 is non-zero, thus if the above comment is right, atomic_impl.h should be defining those.

But that header has:
#if OPAL_HAVE_ATOMIC_CMPSET_32

#if !defined(OPAL_HAVE_ATOMIC_ADD_32)
#define OPAL_HAVE_ATOMIC_ADD_32 1
static inline int32_t
opal_atomic_add_32(volatile int32_t *addr, int delta)
{
   int32_t oldval;
  
   do {
      oldval = *addr;
   } while (0 == opal_atomic_cmpset_32(addr, oldval, oldval + delta));  
   return (oldval + delta);
}
#endif  /* OPAL_HAVE_ATOMIC_CMPSET_32 */

but as OPAL_HAVE_ATOMIC_ADD_32 is defined, just defined to 0, this isn't included.  Probably this isn't tested.

The GCC inline assembly test in configury fails because the inline asm it is testing is wrong.
int
main ()
{
int ret = 1;
int negone = -1;
__asm__ __volatile__ ("xaddl %1,%0" : "=m"(ret), "+r"(negone));
return ret;
;
return 0;
}
doesn't tell gcc that "m" (ret) is used, therefore it doesn't have to assign value 1 to it.  Seems fixing this cures the TEXTREL, but I haven't analyzed the inline asms openmpi is actually using whether they aren't similarly buggy.

Created attachment 480307 [details]
openmpi-inline-asm.patch

Patch which fixes the inline asm configury detection and with which the library is no longer DT_TEXTREL.  That said, upstream should be at least told that it is buggy if inline asm configury fails for ia32.

Could be "+m" (ret) too, but I think the "=m" + "m" variant should cover even prehistoric buggy gccs while "+m" might not work well there.

Any progress here (just applying the patch and building + bodhi ought to be enough)?  This is blocking valgrind upgrade to 3.6.1 in F-15 (or any valgrind rebuild whatsoever) for 3 weeks already.

Built in Rawhide.  If you confirm that the build fixes the problem, I can backport it to F15, et all.

Yeah, valgrind builds just fine against openmpi-{,devel-}-1.5-3.fc16 on i?86, while it doesn't against openmpi-{,devel-}-1.5-2.fc15.  None of the openmpi shared libs are DT_TEXTREL anymore as well.

Please build it also into f15, thanks.

openmpi-1.5-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/openmpi-1.5-3.fc15

Package openmpi-1.5-3.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openmpi-1.5-3.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/openmpi-1.5-3.fc15
then log in and leave karma (feedback).

openmpi-1.5-3.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.