linux程序库设置错误,为什么我的Linux应用程序会插入错误的.so库？

我有一个应用程序,我正在构建使用NetCDF C库,NetCDF正在拉入HDF-4库.然而,它正在吸引错误的HDF-4库.

这是我的应用程序的链接方式：

/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

我设置了LD_LIBRARY_PATH非常短：

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

这里是ldd -v输出的摘录：

libdf.so.0 => /new_apps1/hdf4/lib/libdf.so.0 (0x00002af5baabc000)

libmfhdf.so.0 => /new_apps1/hdf4/lib/libmfhdf.so.0 (0x00002af5bad61000)

libnetcdf_c++.so.5 => /new_apps1/netcdf/lib/libnetcdf_c++.so.5 (0x00002af5baf85000)

libhdf5.so.6 => /new_apps1/hdf5/lib/libhdf5.so.6 (0x00002af5bd1e7000)

libgif.so.4 => /usr/lib64/libgif.so.4 (0x0000003a6bc00000)

libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0000003a71000000)

libnetcdf.so.6 => /new_apps1/netcdf/lib/libnetcdf.so.6 (0x00002af5bd682000)

libhdf5_hl.so.6 => /new_apps1/hdf5/lib/libhdf5_hl.so.6 (0x00002af5be272000)

/new_apps1/hdf4/lib/libdf.so.0:

libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6

libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

/new_apps1/hdf4/lib/libmfhdf.so.0:

libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

/new_apps1/netcdf/lib/libnetcdf_c++.so.5:

libgcc_s.so.1 (GCC_3.0) => /apps1/gcc-4.5.0/lib64/libgcc_s.so.1

libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

libstdc++.so.6 (CXXABI_1.3) => /apps1/gcc-4.5.0/lib64/libstdc++.so.6

libstdc++.so.6 (GLIBCXX_3.4) => /apps1/gcc-4.5.0/lib64/libstdc++.so.6

/new_apps1/hdf5/lib/libhdf5.so.6:

libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6

libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6

libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

/new_apps1/netcdf/lib/libnetcdf.so.6:

libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6

libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6

libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

/new_apps1/hdf5/lib/libhdf5_hl.so.6:

libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

到目前为止,LD_LIBRARY_PATH,rpath和ldd中的所有内容都表明它指向我想要引用的HDF(/new_apps1/hdf4/lib/libmfhdf.so.0).但是当我跑步时,Valgrind告诉我它在OLD HDF-4库中死亡(这可能就是为什么它是segfaulting),而不是我试图链接的HDF-4库：

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&) (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&) (ProjTimestampUtil.cc:593)

by 0x70E9BEA: (anonymous namespace)::parseOptions(int, char**) (ProjUtility.cc:190)

by 0x70EAAFB: main(int, char**) (ProjUtility.cc:243)

还有什么地方我的应用程序在动态拉入其他库时获取路径信息？