Я пытаюсь написать функцию Matlab Mex, которая использует libhdf5; Моя установка Linux предоставляет совместно используемые библиотеки и заголовочные файлы libhdf5-1.8. Тем не менее, моя версия Matlab, r2007b, содержит libhdf5.so из версии 1.6. (Matlab.mat файлы начальной загрузки hdf5, видимо). Когда я компилирую mex, он в Segfaults в Matlab. Если я понижаю свою версию libhdf5 до 1.6 (не долгосрочный вариант), код компилируется и работает нормально.

вопрос: как мне решить эту проблему? Как мне сказать, чтобы процесс компиляции mex связывался с /usr/lib64/libhdf5.so.6 вместо /opt/matlab/bin/glnxa64/libhdf5.so.0? Когда я пытаюсь сделать это с помощью-Wl,-rpath-link,/usr/lib64 в моей компиляции я получаю ошибки вроде:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libhdf5.so.0, needed by /opt/matlab/matlab75/bin/glnxa64/libmat.so, may conflict with libhdf5.so.6
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status

    mex: link of 'hdf5_read_strings.mexa64' failed.

make: *** [hdf5_read_strings.mexa64] Error 1

извед. В крайнем случае следует загрузить локальную копию заголовков hdf5-1.6.5 и покончить с этим, но это не является перспективой (обновление версии Matlab будет в моем будущем.). есть идеи?

РЕДАКТИРОВАТЬ: за отличные предложения Рамашаланки, я

А) называетсяmex -v чтобы получить 3gcc команды; последняя - команда компоновщика;

B) вызвал эту команду компоновщика с-v чтобы получитьcollect команда;

В) это называетсяcollect2 -v -t и остальные флаги.

Соответствующие части моего вывода:

/usr/bin/ld: mode elf_x86_64
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/crtbeginS.o
hdf5_read_strings.o
mexversion.o
-lmx (/opt/matlab/matlab75/bin/glnxa64/libmx.so)
-lmex (/opt/matlab/matlab75/bin/glnxa64/libmex.so)
-lhdf5 (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/libhdf5.so)
/lib64/libz.so
-lm (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/libm.so)
-lstdc++ (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so)
-lgcc_s (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libgcc_s.so)
/lib64/libpthread.so.0
/lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2
-lgcc_s (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libgcc_s.so)
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/crtn.o

Итак, на самом делеlibhdf5.so от/usr/lib64 на него ссылаются. Однако, я полагаю, это переопределяется переменной средыLD_LIBRARY_PATH, который моя версия Matlab автоматически устанавливает во время выполнения, чтобы он мог найти свои собственные версии, например.libmex.so, так далее.

Я думаю, чтоcrt_file.c пример работает либо б / у, он не использует функции, которые я использую (H5DOpen, у которого было изменение подписи при переходе с 1.6 на 1.8 (да, я использую-DH5_USE_16_API)), или, что менее вероятно, b / c не затрагивает те части внутреннего пространства Matlab, которые нуждаются в hdf5. извед.