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)