We are pulling our hair out here over a problem where we are trying to install multiple versions of the same product in different directories under /opt. I pulled down the RPM and I cannot find any information on the order of precedence at runtime, other than a reference in the ld.so changelog that is old old old: Changes in version 1.6.7: ... Changed ld-linux.so to use the following order to search for libraries: LD_{ELF_}LIBRARY_PATH, ld.so.cache, rpath, /usr/lib and /lib. My problem is this: the -L option passed on the linker overrides LD_LIBRARY_PATH at runtime. In fact, LD_LIBRARY_PATH seems to be the low man on the totem pole. -rpath also overrides it. This is not in line with the way the run-time linker seems to work on the other architectures we use, (namely Digital Unix) In order for my executables to link against the libraries in the path specified by LD_RUN_PATH, I have to move the directory where I originally compiled the binaries. Then, finally the runtime linker seems to want to take a hint from LD_LIBRARY_PATH Linux already strips out LD_RUN_PATH and LD_LIBRARY_PATH when you are running setuid, so I don't really see how this could be a security problem. Here's some printed evidence of my problem. My binary is compiled with -L /opt/dcs/dcs/lib -ldcs (other libraries) -L /opt/dcs/lib (other libraries). I installed all of my compiled libraries to the version specific directory /opt/dcs_3.3_t/lib and changed LD_LIBRARY_PATH to point to them: eric@uxeric:/bass/home/eric$ echo $LD_LIBRARY_PATH /opt/dcs_3.3_t/telia_dcs/lib:/opt/dcs_3.3_t/eps/lib:/opt/dcs_3.3_t/lib eric@uxeric:/bass/home/eric$ export LD_LIBRARY_PATH eric@uxeric:/bass/home/eric$ export LD_RUN_PATH=$LD_LIBRARY_PATH eric@uxeric:/bass/home/eric$ ldd /opt/dcs_3.3_t/dcs/bin/dcs_plan_stat libdcs.so => /obj/dcs/dcs/lib/libdcs.so (0x40015000) libdcs_dp.so => /obj/dcs/dcs/lib/libdcs_dp.so (0x4021a000) libdisk.so => /opt/dcs/disk/lib/libdisk.so (0x4026d000) libdict_swap.so => /opt/dcs/dict/lib/libdict_swap.so (0x40277000) ... libdl.so.2 => /lib/libdl.so.2 (0x40470000) libmenu.so => /opt/dcs/menu/lib/libmenu.so (0x40474000) librudp.so => /opt/dcs/ip/lib/librudp.so (0x4047c000) librun.so => /opt/dcs/appst/lib/librun.so (0x40488000) librpt.so => /opt/dcs/rpt/lib/librpt.so (0x4049a000) libfile.so => /opt/dcs/file/lib/libfile.so (0x404a7000) libc.so.6 => /lib/libc.so.6 (0x404af000) libfree.so => /opt/dcs/lib/libfree.so (0x405a4000) libcgisam.so => /opt/dcs/lib/libcgisam.so (0x405b9000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) even though LD_LIBRARY_PATH is set, ldd shows that the executable is linking against libraries in /opt/dcs/lib. Now, I move my development environment libraries out of the way: eric@uxeric:/bass/home/eric$ mv /opt/dcs /opt/dcs.o eric@uxeric:/bass/home/eric$ ldd /opt/dcs_3.3_t/dcs/bin/dcs_plan_stat libdcs.so => /obj/dcs/dcs/lib/libdcs.so (0x40015000) libdcs_dp.so => /obj/dcs/dcs/lib/libdcs_dp.so (0x4021a000) libdisk.so => /opt/dcs_3.3_t/lib/libdisk.so (0x4026d000) ... libevent.so => /opt/dcs_3.3_t/lib/libevent.so (0x40459000) libdl.so.2 => /lib/libdl.so.2 (0x40470000) libmenu.so => /opt/dcs_3.3_t/lib/libmenu.so (0x40474000) librudp.so => /opt/dcs_3.3_t/lib/librudp.so (0x4047c000) librun.so => /opt/dcs_3.3_t/lib/librun.so (0x40488000) librpt.so => /opt/dcs_3.3_t/lib/librpt.so (0x4049a000) libfile.so => /opt/dcs_3.3_t/lib/libfile.so (0x404a7000) libc.so.6 => /lib/libc.so.6 (0x404af000) libfree.so => /opt/dcs_3.3_t/lib/libfree.so (0x405a4000) libcgisam.so => /opt/dcs_3.3_t/lib/libcgisam.so (0x405b9000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
I just noticed something that was inconsistent about what I reported, the first -L option was -L/obj/dcs/dcs/lib, hence why in the output of ldd shows them as linking against files in /obj/dcs/dcs/lib instead of /opt/dcs_3.3_t or /opt/dcs/lib Also, I am not runinng setuid. eric@uxeric:/usr/src/redhat/BUILD/ld.so-1.9.5/d-link$ id uid=209(eric) gid=257(dev) groups=257(dev) Just for kicks, I export "LD_BIND_NOW" with a value of 1 and that didn't seem to help either.
... Please close this bug. I have found a way to make this work and it looks like I was (obviously) confused over the difference between LD_RUN_PATH and LD_LIBRARY_PATH. I'll just write down what I believe I have figured out if anyone else is interested. ld -rpath <dir> means that the path to find the library is encoded in the executable and the linker WILL NOT USE LD_LIBRARY_PATH at runtime. This is in the man page for ld. LD_RUN_PATH when used at COMPILE time for making an executable seems to do the same thing as specifying -rpath to ld. I was under the mistaken impression that the LD_RUN_PATH was the same as LD_LIBRARY_PATH. This may not be entirely correct, but what I have observed is that if you link a shared library and specify -L<dir> -l<someotherlibrary> that this is also the same as specifying -rpath <dir> on the ld link line. You can get around this with -rpath-link <dir> which tells the linker to use <dir> at compile time, but allow LD_LIBRARY_PATH to work at runtime. sorry for wasting your time!
assigned to jakub