title: Why is my Linux application pulling in the wrong .so library?
body: <p>I have an application I'm building that's using the NetCDF C++ library, and NetCDF is pulling in the HDF-4 libary.  However, it's pulling in the <em>wrong</em> HDF-4 library.</p>
  
  <p>Here's how my app is linked:</p>
  
  <pre><code>/apps1/intel/bin/icpc -gxx-name=/apps1/gcc-4.5.0/bin/g++ -shared -o lib/libMyCustom.so
    -Llib  -L/apps1/boost-1.48.0/lib -Wl,-rpath=/apps1/boost-1.48.0/lib
    -L/apps1/gdal-1.8.0-jasper/lib -Wl,-rpath=/apps1/gdal-1.8.0-jasper/lib
    -L/new_apps1/hdf4/lib -Wl,-rpath=/new_apps1/hdf4/lib -L/new_apps1/netcdf/lib
    -Wl,-rpath=/new_apps1/netcdf/lib -lboost_system -lboost_serialization
    -lboost_date_time -lboost_thread -lgdal -ldf -lmfhdf -lnetcdf_c++ 
    MyProj/obj/ProjUtility.o  MyProj/obj/ProjMetadataException.o
    MyProj/obj/ProjTimestampUtil.o 
  </code></pre>
  
  <p>I have set my LD_LIBRARY_PATH very short:</p>
  
  <pre><code>LD_LIBRARY_PATH=/new_apps1/hdf4/lib:/new_apps1/hdf5/lib:
    /apps1/intel/composerxe/lib/intel64:/apps1/gcc-4.5.0/lib64:/apps1/gcc-4.5.0/lib
  </code></pre>
  
  <p>And here is an excerpt from the ldd -v output:</p>
  
  <pre><code>    libdf.so.0 =&gt; /new_apps1/hdf4/lib/libdf.so.0 (0x00002af5baabc000)
      libmfhdf.so.0 =&gt; /new_apps1/hdf4/lib/libmfhdf.so.0 (0x00002af5bad61000)
      libnetcdf_c++.so.5 =&gt; /new_apps1/netcdf/lib/libnetcdf_c++.so.5 (0x00002af5baf85000)
      libhdf5.so.6 =&gt; /new_apps1/hdf5/lib/libhdf5.so.6 (0x00002af5bd1e7000)
      libgif.so.4 =&gt; /usr/lib64/libgif.so.4 (0x0000003a6bc00000)
      libpng12.so.0 =&gt; /usr/lib64/libpng12.so.0 (0x0000003a71000000)
      libnetcdf.so.6 =&gt; /new_apps1/netcdf/lib/libnetcdf.so.6 (0x00002af5bd682000)
      libhdf5_hl.so.6 =&gt; /new_apps1/hdf5/lib/libhdf5_hl.so.6 (0x00002af5be272000)
  
      /new_apps1/hdf4/lib/libdf.so.0:
              libc.so.6 (GLIBC_2.3) =&gt; /lib64/libc.so.6
              libc.so.6 (GLIBC_2.2.5) =&gt; /lib64/libc.so.6
      /new_apps1/hdf4/lib/libmfhdf.so.0:
              libc.so.6 (GLIBC_2.2.5) =&gt; /lib64/libc.so.6
      /new_apps1/netcdf/lib/libnetcdf_c++.so.5:
              libgcc_s.so.1 (GCC_3.0) =&gt; /apps1/gcc-4.5.0/lib64/libgcc_s.so.1
              libc.so.6 (GLIBC_2.2.5) =&gt; /lib64/libc.so.6
              libstdc++.so.6 (CXXABI_1.3) =&gt; /apps1/gcc-4.5.0/lib64/libstdc++.so.6
              libstdc++.so.6 (GLIBCXX_3.4) =&gt; /apps1/gcc-4.5.0/lib64/libstdc++.so.6
      /new_apps1/hdf5/lib/libhdf5.so.6:
              libm.so.6 (GLIBC_2.2.5) =&gt; /lib64/libm.so.6
              libc.so.6 (GLIBC_2.3) =&gt; /lib64/libc.so.6
              libc.so.6 (GLIBC_2.2.5) =&gt; /lib64/libc.so.6
      /new_apps1/netcdf/lib/libnetcdf.so.6:
              libm.so.6 (GLIBC_2.2.5) =&gt; /lib64/libm.so.6
              libc.so.6 (GLIBC_2.3) =&gt; /lib64/libc.so.6
              libc.so.6 (GLIBC_2.2.5) =&gt; /lib64/libc.so.6
      /new_apps1/hdf5/lib/libhdf5_hl.so.6:
              libc.so.6 (GLIBC_2.2.5) =&gt; /lib64/libc.so.6
  </code></pre>
  
  <p>So far, everything in the LD_LIBRARY_PATH, rpath, and ldd indicate that it's pointing to the HDF that I want to reference (/new_apps1/hdf4/lib/libmfhdf.so.0).  But when I run, Valgrind is telling me that it's dying in the OLD HDF-4 library (which is probably why it's segfaulting), instead of the HDF-4 library I'm attempting to link against:</p>
  
  <pre><code> Invalid read of size 4
      at 0x67CF765: NC_var_shape (in /apps1/hdf-4.2.6/lib/libmfhdf.so.0.0.0)
      by 0x91327CA: nc_get_NC (v1hpg.c:1113)
      by 0x91303C0: l3nc__open_mp (nc.c:1096)
      by 0x915B279: nc3d__open_mp (dapdispatch3.c:336)
      by 0x914A752: nc3d_open (ncdap3.c:94)
      by 0x911F8A2: l4nc_open_file (nc4file.c:2338)
      by 0x916A290: nc4d_open_file (ncdap4.c:122)
      by 0x911CDDF: nc__open (nc4file.c:2407)
      by 0x69E85F8: NcFile::NcFile(char const*, NcFile::FileMode, unsigned long*, unsigned long, NcFile::FileFormat) (netcdf.cpp:384)
      by 0x710F0B8: getData(std::string const&amp;) (ProjTimestampUtil.cc:593)
      by 0x70E9BEA: (anonymous namespace)::parseOptions(int, char**) (ProjUtility.cc:190)
      by 0x70EAAFB: main(int, char**) (ProjUtility.cc:243)
    Address 0x1051 is not stack'd, malloc'd or (recently) free'd
  
  
   Process terminating with default action of signal 11 (SIGSEGV)
    Access not within mapped region at address 0x1051
      at 0x67CF765: NC_var_shape (in /apps1/hdf-4.2.6/lib/libmfhdf.so.0.0.0)
      by 0x91327CA: nc_get_NC (v1hpg.c:1113)
      by 0x91303C0: l3nc__open_mp (nc.c:1096)
      by 0x915B279: nc3d__open_mp (dapdispatch3.c:336)
      by 0x914A752: nc3d_open (ncdap3.c:94)
      by 0x911F8A2: l4nc_open_file (nc4file.c:2338)
      by 0x916A290: nc4d_open_file (ncdap4.c:122)
      by 0x911CDDF: nc__open (nc4file.c:2407)
      by 0x69E85F8: NcFile::NcFile(char const*, NcFile::FileMode, unsigned long*, unsigned long, NcFile::FileFormat) (netcdf.cpp:384)
      by 0x710F0B8: getData(std::string const&amp;) (ProjTimestampUtil.cc:593)
      by 0x70E9BEA: (anonymous namespace)::parseOptions(int, char**) (ProjUtility.cc:190)
      by 0x70EAAFB: main(int, char**) (ProjUtility.cc:243)
  </code></pre>
  
  <p>Where else is my app getting path info when dynamically pulling in other libraries?</p>