Я пытаюсь написать mex-функцию matlab, которая использует 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 будет в моем будущем.). есть идеи?
РЕДАКТИРОВАТЬ: за отличные предложения Рамашаланки, я
A) вызывается mex -v для получения команд 3 gcc; последняя команда компоновщика;
B) вызвал эту команду компоновщика с -v, чтобы получить команду collect;
C) назвали это 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 работает либо b / c, он не использует функции, которые я использую (H5DOpen, у которого было изменение сигнатуры при переходе с 1.6 на 1.8 (да, я использую -DH5_USE_16_API)), или, что менее вероятно, b / c не затрагивает части внутреннего пространства Matlab, для которых требуется hdf5. извед.