This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/39785] LD_RUN_PATH ignored



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]