title: shared library locations for matlab mex files:
body: <p>I am trying to write a matlab mex function which uses libhdf5; My Linux install provides libhdf5-1.8 shared libraries and headers. However, my version of Matlab, r2007b, provides a libhdf5.so from the 1.6 release. (Matlab <code>.mat</code> files bootstrap hdf5, evidently). When I compile the mex, it segfaults in Matlab. If I downgrade my version of libhdf5 to 1.6 (not a long-term option), the code compiles and runs fine.</p>
  
  <p>question: how do I solve this problem? how do I tell the mex compilation process to link against /usr/lib64/libhdf5.so.6 instead of /opt/matlab/bin/glnxa64/libhdf5.so.0 ? When I try to do this using <code>-Wl,-rpath-link,/usr/lib64</code> in my compilation, I get errors like:</p>
  
  <pre><code>/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
  </code></pre>
  
  <p>ack. the last resort would be to download a local copy of the hdf5-1.6.5 headers and be done with it, but this is not future proof (a Matlab version upgrade is in my future.). any ideas?</p>
  
  <p>EDIT: per Ramashalanka's excellent suggestions, I </p>
  
  <p>A) called <code>mex -v</code> to get the 3 <code>gcc</code> commands; the last is the linker command;</p>
  
  <p>B) called that linker command with a <code>-v</code> to get the <code>collect</code> command;</p>
  
  <p>C) called that <code>collect2 -v -t</code> and the rest of the flags.</p>
  
  <p>The relevant parts of my output:</p>
  
  <pre><code>/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
  </code></pre>
  
  <p>So, in fact the <code>libhdf5.so</code> from <code>/usr/lib64</code> is being referenced. However, this is being overriden, I believe, by the environment variable <code>LD_LIBRARY_PATH</code>, which my version of Matlab automagically sets at run-time so it can locate its own versions of e.g. <code>libmex.so</code>, etc.</p>
  
  <p>I am thinking that the <code>crt_file.c</code> example works either b/c it does not use the functions I am using (<code>H5DOpen</code>, which had a signature change in the move from 1.6 to 1.8 (yes, I am using <code>-DH5_USE_16_API</code>)), or, less likely, b/c it does not hit the parts of Matlab internals that need hdf5. ack.</p>