Suppose you have an executable compiled for /usr/local on a SVR4 UNIX system, or on GNU/Linux (this is a severe violation of SVR4 and LSB FHS standards [1][2]). With these tools, you could theoretically unlink the application, then re-link it with $ORIGIN linker keyword, and install it into /opt, where the standards say it belongs. (Same for 3rd party unbundled applications which were linked to use their own shared libraries residing in /usr/lib[64] or /usr/lib[/64], another very serious architectural offense.)

Let's build upon the author's example in order to demonstrate the above (imagine for a moment that ls(1) is a third party, unbundled application which clashes with vendor's own ls(1) as delivered with the operating system):

  % wcc -c /bin/ls -o /tmp/ls.o

(GCC)

  % gcc -shared -Wl,-R'$ORIGIN:$ORIGIN/../../lib:$ORIGIN/../../lib:/opt/local/lib' /tmp/ls.o -o /tmp/ls

(Sun Studio)

  % cc -G -Wl,-R'$ORIGIN:$ORIGIN/../../lib:$ORIGIN/../../lib:/opt/local/lib' /tmp/ls.o -o /tmp/ls

[1] https://docs.oracle.com/cd/E19455-01/817-5431/6mksv3nvi/inde...

[2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etc... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#opt... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#var...