> Actually you can fix this with /etc/ld.so.conf, just make sure the lib dir(s) > are in, say, /etc/ld.so.conf.d/oracle or /etc/ld.so.conf and run ldconfig. > > no need to use LD_LIBRARY_PATH
That only works on GNU/Linux; if the libraries and binaries are linked with -R, it is not necessary to set either LD_LIBRARY_PATH nor /etc/ld.so.conf, and that technique works on both GNU/Linux and all the System V UNIXes. As an additional measure, using the $ORIGIN link editor keyword will encode RUNPATH and RPATH into the ELF header, [9] RUNPATH $ORIGIN:$ORIGIN/../lib:$ORIGIN/../../lib:/opt/lib [10] RPATH $ORIGIN:$ORIGIN/../lib:$ORIGIN/../../lib:/opt/lib ...causing the runtime linker to look in the current directory of the binary/library first ($ORIGIN), then in the other paths relative to the directory where the binary/library are ($ORIGIN:$ORIGIN/../lib:$ORIGIN/../../lib). This feature is supported by GNU ld, and ld's in Solaris, IRIX and HP-UX, and possibly other UNIX operating systems. After this, binary executables and libraries can be relocated anywhere, so long as the relative filesystem structure is preserved. The neat thing about the $ORIGIN keyword is that it causes the linker to always correctly find symbols in libraries and binaries, without having to depend on LD_LIBRARY_PATH or /etc/ld.so.conf. I would pay good money to find out why Oracle does not do this with their instant client libraries. _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
