In openmpi-1.5-2.fc15.i686 readelf -Wd /usr/lib/openmpi/lib/libopen-pal.so.1 | grep TEXTREL 0x00000016 (TEXTREL) 0x0 which is wrong, and causes valgrind build failure: configure:8503: checking primary target for usable MPI2-compliant C compiler and mpi.h configure:8527: /usr/lib/openmpi/bin/mpicc -o conftest -m32 conftest.c >&5 /usr/lib/openmpi/bin/mpicc: error while loading shared libraries: /usr/lib/openmpi/lib/libopen-pal.so.1: cannot restore segment prot after reloc: Permission denied All the TEXTREL violations are in calls to opal_atomic_add_32 and opal_atomic_sub_32, like: 00041f3b 0002cb02 R_386_PC32 0001d116 opal_atomic_add_32 00010672 0001e902 R_386_PC32 0001d126 opal_atomic_sub_32 Please fix this. openmpi-1.4.3-7.fc14.i686 was correct.
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.