------- Comment #4 from floris dot bruynooghe at gmail dot com 2009-04-21 19:22 ------- Sure, that's why you should always use it together with --enable-new-dtags when using GNU ld so you get a RUNPATH (note that for Solaris ld this is not needed, you get a RUNPATH automatically if you use -R there).
But while I can see how this could be an argument against LD_RUN_PATH when GNU ld is used --you need an extra option to the linker in any case-- it still seems useful on other userlands (e.g. Solaris, AIX (where the env var is LIBPATH but other semantics and problems are the same)). Note that ironically enough the LD_RUN_PATH environment variable will work on a GNU-userland system and not on Solaris where it is more useful due to the automatic RUNPATH. Or is RUNPATH bad too? That can be overwritten by ld.so when you use the LD_LIBRARY_PATH env var no? (Sorry if I'm abusing this bug report, feel free to refer me to a more appropriate place to discuss these issues. Again, if you could refer me to documentation that explains how to make an executable that looks for shared libs in say /opt/example.com/lib without using RUNPATH that would help me understanding why this is a non-bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39785
