Можно ли использовать -Wl, -dynamic-linker для генерации правильного ELF, связанного с соответствующими файлами общего объекта?

Я устанавливаю openmpi-1.4.5 из исходного кода в gentoo с обратной совместимостью GLIBC_2.11 для работы под NFS (Cluster HPC) с одним вычислительным узлом debian gnu / linux (squeeze).
похоже на наличие двух систем с независимыми книжными магазинами, но обе они могут выполнять файлы в высокопроизводительной сети. Идея заключается в том, что обе операционные системы могут запускать файлы через MPI.
Вот шаги, которые я выполнил, чтобы настроить и сделать:

configure:
.././configure --prefix=/usr/local/ompi-compat --build=x86_64-pc-linux-gnu --with-openib     CC=x86_64-pc-linux-gnu-gcc -include /usr/local/include/gcc-preinclude.h

make:
make LDFLAGS="-Wl,-rpath -Wl,/spoa/usr/lib64 -Wl,-rpath -Wl,/usr/local/ompi-compat/lib" 2>&1 | tee make02.log

Позже этап изготовления нарушается:

…

..

libtool: compile:  x86_64-pc-linux-gnu-gcc -include /usr/local/include/gcc-preinclude.h  -DHAVE_CONFIG_H -I. -I../../.././opal/asm -I../../opal/include -I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../../. -I../.. -I../../.././opal/include -I../../.././orte/include -I../../.././ompi/include -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT atomic-asm.lo -MD -MP -MF .deps/atomic-asm.Tpo -c atomic-asm.S  -fPIC -DPIC -o .libs/atomic-asm.o

/usr/local/include/gcc-preinclude.h: Сообщения ассемблера:

/usr/local/include/gcc-preinclude.h:1: Error: invalid character '(' in mnemonic
make[2]:  [atomic-asm.lo] Error 1
make[2]: Leaving directory `/usr/local/src/openmpi-1.4.5/build/opal/asm'
make[1]:  [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/openmpi-1.4.5/build/opal'
make:  [all-recursive] Error 1

Есть проблемы с модулем asm, потому что я использую одну адаптацию include c для исключения символов memcpy @ 2_2_5 из заголовка /usr/local/include/gcc-preinclude.h:

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

Я исправил эту ситуацию в папке add —tag = CC и вырезал «-include /usr/local/include/gcc-preinclude.h» из компилятора x86_64-pc-linux-gnu-gcc:

/bin/sh ../../libtool  --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../.././opal/asm -I../../opal/include -I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/linux/plpa/src/libplpa   -I../../../. -I../.. -I../../.././opal/include -I../../.././orte/include -I../../.././ompi/include    -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT atomic-asm.lo -MD -MP -MF $depbase.Tpo -c -o atomic-asm.lo atomic-asm.S &&mv -f $depbase.Tpo $depbase.Plo

Компилировать с этой строкой в ​​папку opal / asm / замечательно!

Вернитесь в основную папку сборки и продолжите компиляцию:

make LDFLAGS="-Wl,-rpath -Wl,/spoa/usr/lib64 -Wl,-rpath -Wl,/usr/local/ompi-compat/lib" 2>&1 | tee make02.log

Несколько минут после компиляции вступает в силу.

Но когда я проверяю какой-нибудь исполняемый файл на запуск, он отображается как «Ошибка сегментации»:

cd opal/tools/wrappers/.libs

.libs # ./opal_wrapper
Segmentation fault

Так со всеми исполняемыми файлами …

Now, veryfing the Shared Library path linking to ELF File:
ldd opal_wrapper
linux-vdso.so.1 =>  (0x00007fff3ffff000)
libopen-pal.so.0 => /usr/local/ompi-compat/lib/libopen-pal.so.0 (0x00002b8ea8239000)
libdl.so.2 => /spoa/usr/lib64/libdl.so.2 (0x00002b8ea8493000)
libnsl.so.1 => /spoa/usr/lib64/libnsl.so.1 (0x00002b8ea8697000)
libutil.so.1 => /spoa/usr/lib64/libutil.so.1 (0x00002b8ea88af000)
libm.so.6 => /lib64/libm.so.6 (0x00002b8ea8ad5000)
libpthread.so.0 => /spoa/usr/lib64/libpthread.so.0 (0x00002b8ea8d56000)
libc.so.6 => /spoa/usr/lib64/libc.so.6 (0x00002b8ea8f72000)
/lib64/ld-linux-x86-64.so.2 (0x00002b8ea8017000)

Существуют общие объектные файлы, связанные с -rpath. Я использую основные оригинальные общие объекты, поставляемые с debian «squeeze» в папку / spoa / usr / lib64 и связываю их ОК! но я думаю, что сбой происходит от ссылки на оригинальный gentoo dynamic-linker /lib64/ld-linux-x86_64.so.2

There is my debian "squeeze" main toolchain shared objects:
ls  /spoa/usr/lib64/
ld-2.11.3.so          libdl.so.2            libnsl-2.11.3.so      libstdc++.so.6.0.13        libz.so.1.2.3.4
ld-linux-x86-64.so.2  libgcc_s.so           libnsl.so.1           libutil-2.11.3.so
libc-2.11.3.so        libgcc_s.so.1         libpthread-2.11.3.so  libutil.so.1
libc.so.6             libgfortran.so.3.0.0  libpthread.so.0       libz.so
libdl-2.11.3.so       libm.so               libstdc++.so.6        libz.so.1

Если я вручную изменить компоновщик для этого исполняемого файла запустить в Gentoo & Debian (через NFS) и, наконец, работает:

/bin/sh ../../../libtool --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc -include    /usr/local/include/gcc-preinclude.h  -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -pthread -fvisibility=hidden  -L/spoa/usr/lib64 -Wl,-rpath -Wl,/spoa/usr/lib64 -o opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lnsl -lutil  -lm -Wl,-rpath -Wl,/usr/local/ompi-compat/lib -Wl,-dynamic-linker /spoa/usr/lib64/ld-linux-x86-64.so.2

Результат:

libtool: link: x86_64-pc-linux-gnu-gcc -include /usr/local/include/gcc-preinclude.h -O3     -DNDEBUG -finline-functions -fno-strict-aliasing -pthread -fvisibility=hidden -Wl,-rpath -    Wl,/spoa/usr/lib64 -o .libs/opal_wrapper opal_wrapper.o -Wl,-rpath -Wl,/usr/local/ompi-    compat/lib -Wl,-dynamic-linker /spoa/usr/lib64/ld-linux-x86-64.so.2  -L/spoa/usr/lib64     ../../../opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm -pthread

и ldd показывают правильно соответствующий компоновщик:

wrappers ldd .libs/opal_wrapper

linux-vdso.so.1 =>  (0x00007fffc75a7000)
libopen-pal.so.0 => /usr/local/ompi-compat/lib/libopen-pal.so.0 (0x00002b396dd38000)
libdl.so.2 => /spoa/usr/lib64/libdl.so.2 (0x00002b396df91000)
libnsl.so.1 => /spoa/usr/lib64/libnsl.so.1 (0x00002b396e196000)
libutil.so.1 => /spoa/usr/lib64/libutil.so.1 (0x00002b396e3ae000)
libm.so.6 => /lib64/libm.so.6 (0x00002b396e5d3000)
libpthread.so.0 => /spoa/usr/lib64/libpthread.so.0 (0x00002b396e855000)
libc.so.6 => /spoa/usr/lib64/libc.so.6 (0x00002b396ea71000)
/spoa/usr/lib64/ld-linux-x86-64.so.2 (0x00002b396db18000)

Мой вопрос Можно ли использовать -Wl, -dynamic-linker для генерации правильного ELF, связанного с соответствующими файлами общего объекта?

Бег:
./opal_wrapper
Не удается открыть файл конфигурации /usr/local/ompi-compat/share/openmpi/opal_wrapper-wrapper-data.txt
Ошибка разбора файла данных opal_wrapper: не найден

Некоторые из информации о моем хосте:

hostname = master
uname -m = x86_64
uname -r = 3.4.5-gentoo
uname -s = Linux
uname -v = #1 SMP Mon Jul 23 21:35:06 UTC 2012