общие местоположения библиотеки для matlab файлов MEX:

Я пытаюсь записать 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

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

Править: на превосходные предложения Ramashalanka, меня

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

B) названный, что команда компоновщика с a -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. ack.