If you create your own shared object files and do not install them in /usr/lib, then you need to set your LD_LIBRARY_PATH environment variable so that the runti

If you create your own shared object files and do not install them in /usr/lib, then you need to set your LD_LIBRARY_PATH environment variable so that the runtime linker can find them and load them at run time. A better approach would be to use the $ORIGIN linker keyword (-R works in gcc by special dispensation for compatibility with every other linker in existence, and is portable, as opposed to -rpath): gcc -L/home/newhall/lib -R'$ORIGIN:$ORIGIN/../lib' -lmine -o myprog myprog.c because unfortunately the $ORIGIN keyword includes the $, to embed it effectively into Makefiles and shell scripts, the following is needed in the environment: O='$$O'; export O ORIGIN='$ORIGIN'; export ORIGIN this way, both shell and make will expand $ORIGIN to $ORIGIN, without the need to recursively escape anything. $ORIGIN linker keyword is supported by GNU ld, Solaris / illumos ld, and HP-UX's ld. https://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the https://blogs.oracle.com/ali/entry/avoiding_ld_library_path_... https://blogs.oracle.com/rie/entry/tt_ld_library_path_tt https://blogs.oracle.com/rie/entry/tt_ld_library_path_tt Also, unless one is an operating system vendor, one may not install anything into /usr, as that is the vendor's namespace and having a clash with the vendor could bring one's production down in case of upgrades, were the vendor to deliver the same software. The System V and LSB FHS specifications state that /opt is for 3rd party and unbundled applications, /etc/opt for configuration, and /var/opt for data. Unfortunately, the essay says nothing about library interface versioning with linker map files, for backward compatibility, so that one single shared object library can be used by all versions of the consuming software simultaneously.